A couple of points:
1) chmod and the sysopen* call above set the file mode not the permission
2) A file mode of 0666 is generally bad as it is generally allows more access to the file than is needed (do you really want everyone to be able to read/change/delete your file?)
3) If you need to modify owner or the group membership, use chown
CC
Updated:
Ok, you can't actually delete the file unless you have write access to the directory whihch holds the file. You can, however, blank out the file. For example:
> my.file
will reduce the file to zero bytes without actually having write access to the directory. The file isn't deleted but it certainly isn't very useful now.
* if your umask is sane (ie 022) then the sysopen (FILEHANDLE, ">>$filepath",O_CREAT, 0666) will not be inherently insecure. | [reply]
[d/l]
[select] |
A file mode of 0666 is generally bad
Perhaps, but a mode of 0666 on sysopen is generally good, because it gives the user of the program
the most control. Remember that the mode given to sysopen
is masked with the umask of the user. A mode of 0666 gives
the user the option to say who can read/write the file, by
using commonly used umasks of 022, 027 and 077. If you use
a mode of 0644 or 0600, you rob the user of options.
For executables, use a mode of 0777.
Abigail
| [reply] |
Hmmm, I have to respectfully disagree with you on this one. A file mode of 0644 or 0600 do not restrict the file owners options as the owner can still read/update/delete the file. These more restricted file modes only limit what other users can do with the file.
Having had a bit more time to think on this (also more caffine), I still think a mask of 0666 with sysopen is less than desirable for a couple of reasons:
- what if your umask is not set sanely?
- what if your umask changes?
If you don't supply a mask to sysopen it will just create the file and apply the umask at create time. Personally, I think paranoia is good and chmoding the file immediately after the create to most restricted mode possible while still making the file available to those processes and/or users that need to access the file is the best policy.
CC
| [reply]
[d/l] |
Not to be terribly nitpicky but the file permissions (at least on the *nixes I've used) don't have any control over wether or not you can delete the file. You need write permissions on the directory the file is in to delete it.
i.e.
% ls -al
total 12
4 drwxr-xr-x 2 notme notmygroup 4096 Mar 17 11:12 ./
4 drwxr-xr-x 101 me mygroup 4096 Mar 17 11:12 ../
4 -rw-rw-rw- 1 me mygroup 42 Mar 17 11:12 foo.foo
% rm foo.foo
rm: cannot remove `foo.foo': Permission denied
% sudo chmod 777 .
% rm foo.foo
| [reply]
[d/l] |
Hi,
Thanks to everyone who contributed to this discussion. I've learned a lot.
I've decided to use the umask method suggested and would like to thank Bart for providing the example code snippet.
Best wishes
Sid
| [reply] |
What happens when you try it?
(And you probably should also read perldoc perlopentut which gives examples of correct use of sysopen().)
| [reply]
[d/l]
[select] |