in reply to Re: Re: Setting permissions as text file is created
in thread Setting permissions as text file is created

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

  • Comment on Re: Setting permissions as text file is created

Replies are listed 'Best First'.
Re: Re: Setting permissions as text file is created
by coec (Chaplain) on Mar 18, 2004 at 01:19 UTC
    I'm not wanting to start a flame here but I disagree on a couple of points:

      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?

    IMO it is very much the sys admins role to review security (including umasks) and make appropriate changes. Data files (critically important or otherwise) should not be world writable, group writable maybe, extended ACLs even, but not world writable.

      Don't trust programmers who think they know better than the user what's good for them.

    Agreed, its not up to the program to decide these things. These details should be in the functional spec the programmer is working from.

      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.

    My experience with users is that generally they do not know what file modes/ownership is required to do what they need. The site I'm at now had a policy of all data files having a mode of 666. They had no idea of why 666 was a) unnecessary and b) bad. Staying with the site I'm at now, most of the users (6570 out of 6595) do not have shell access and wouldn't know a umask if it bit them. Their umask is set, they have no way of changing it, and for a long time the umask was set to '0' (which I would not call sane).

    Every site is different and each has users of varying skills/knowledge and requirements. The point I was initially trying to make was: 'don't set the file access mode higher than it needs to be'.

    CC

      So, you think that programs like 'cp', or even perl (for files opened with 'open') should be restrictive, and always generate files with permission '0400' (why stop at 0600?)?

      If the answer is yes, there's little point in using a umask, is there?

      Their umask is set, they have no way of changing it, and for a long time the umask was set to '0' (which I would not call sane).
      Ah, I see. So, because your site used to have a dumb policy, all programs should create files with as restrictive permissions as possible? Now, that's what I call stupid. Fix your site-wide policies.

      Abigail