A file mode of 0666 is generally bad

Abigail

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

Read my post carefully. The mode given to sysopen is not the file permission mode. The resulting file permission mode is the result of the mode given to sysopen, masked by the umask.

A file mode of 0644 or 0600 do not restrict the file owners options as the owner can still read/update/delete the file.

Read my post carefully. I said A mode of 0666 gives the user the option to say who can read/write the file, which is something entirely different from the permissions of the owner of a file.

Let me quote man perlopentut

       Permissions A la mode

       If you omit the MASK argument to "sysopen", Perl uses the
       octal value 0666.  The normal MASK to use for executables
       and directories should be 0777, and for anything else,
       0666.

       Why so permissive?  Well, it isn't really.  The MASK will
       be modified by your process's current "umask".  A umask is
       a number representing disabled permissions bits; that is,
       bits that will not be turned on in the created files' per­
       missions field.

       For example, if your "umask" were 027, then the 020 part
       would disable the group from writing, and the 007 part
       would disable others from reading, writing, or executing.
       Under these conditions, passing "sysopen" 0666 would cre­
       ate a file with mode 0640, since "0666 & ~027" is 0640.

       You should seldom use the MASK argument to "sysopen()".
       That takes away the user's freedom to choose what permis­
       sion new files will have.  Denying choice is almost always
       a bad thing.  One exception would be for cases where sen­
       sitive or private data is being stored, such as with mail
       folders, cookie files, and internal temporary files.
[download]

Abigail

Well, you modified your post, so you get a second reply. You're still wrong though.

what if your umask is not set sanely?

Well, that's the user's choice, isn't? Who are you to determine whether a user has set his/her umask "sanely"? What umasks are sane, and which one aren't?

what if your umask changes?

Well, what about?

If you don't supply a mask to sysopen it will just create the file and apply the umask at create time.

Djee. If you don't supply a mask to sysopen, sysopen will use 0666 or 0777. That doesn't result in less permissions than supplying 0666.

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.

I agree paranoia is good. Don't trust programmers who think they know better than the user what's good for them. In general, you have no idea which processes or users are going to need access to the files created - so you better leave the decision what appropriate file permissions are to the user.

Abigail

% 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
[download]

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

My mistake. You're correct. To delete the file you need to have write access to the directory which holds the file.