-1

It is specified in various documentation on the net that linux/unix file base permissions are 666 with regards to how umask manipulates.

This is also relevant with regards to the fact that default ACL permissions enforce a rw mask for files created under a default ACL permission.

  1. Can the file base permissions of 666 be changed?
  2. Is the behavior with regards to the mask generated for files created under a default ACL that appears to mimic said file base permissions of 666 (deactivating execute) in fact a function of the said file base permissions?
  3. If #1 is a configurable option, where is said configuration?

This is with regards to atleast the following system:

Ubuntu 12.04.3

However I would presume this behavior is common to a lot of unix.

MetaChrome
  • 133
  • 10
  • 1
    I'm slightly confused by this question (sorry). Could you edit it to be a bit more concrete about what you're doing, what you want, and what you actually get? – MadHatter Dec 04 '13 at 10:33
  • What don't you understand? I am asking why the file base permissions are 666 as opposed to 777, (and if this is configurable) and the effects of that in the various specified contexts. – MetaChrome Dec 04 '13 at 10:37
  • 5
    It's the specifed contexts that interest and confuse me (I think the question is OT if it's just "*why is X like it is*", as those are issues of opinion, and I don't believe that default can be easily changed). Could you give a solid example of the undesirable result that arises from combining the umask-base-permission-of-666 with default-ACL-permissions? That will mean, as I said, showing us what you're doing, telling us what you expected, and showing us what you got. In addition, a base permission of 666 does not "*deactivate write**", which doesn't help my confusion. – MadHatter Dec 04 '13 at 10:40
  • Sorry I meant deactivate execute. With Default ACL permissions set to rwx, files created under said permissions do not have the execute permission (and this is facilitated by a mask). I am not questioning the validity of the 666 file base permission, or offering my opinion on the matter, I wish to understand the root of this configuration. This is not off topic. This is specified somewhere in the execution of the operating system or file system. "I don't believe that default can be easily changed" is very helpful but a specification as to it's configuration/source is preferred. – MetaChrome Dec 04 '13 at 10:57
  • 1
    I don't think it's configurable, I think it's enforced by the kernel. To get more concrete about changing it, you'll need to specify OS, and if Linux, distro and version. If (2) above isn't a solid issue, could you take it out of the question? – MadHatter Dec 04 '13 at 11:30
  • I think it's relevant, but I doubt anyone cares about this question on this particular site. I am configuring with ACL and the masked permissions provided by ACL appear to be a function of this 666 base file permission. However, it has not been specified if ACL functionality is reflecting this from it's own configuration or implicitly from this file base permission provided by the kernel. I mean both these questions are not the end of the world, but if 666 is not configurable, than in some instances, it may be necessary to route file creation through a custom executable. – MetaChrome Dec 04 '13 at 11:59
  • 1
    **Please** read what I'm asking for. I don't doubt this is an issue for you, but if you don't **show** us the issue, we can't do much to help. – MadHatter Dec 04 '13 at 13:11
  • The question and use case is that I possibly want to change the file base permissions. Or maybe I just want to know where it's configured and if anyone knows it would save everyone some time. I have 700+ worth of questions on stackoverflow with no one ever having a problem with what I ask. I code in Haxe, C++, Java, Actionscript, PHP. I don't ask questions for my own entertainment or from a lack of searching. Frankly I dont care what you think because the meta of this site (whatever it is) makes it unworthwhile to use if there is an inquisition from the mods for every question they dont know. – MetaChrome Dec 04 '13 at 14:11
  • If no one knows the linux kernel well enough to answer this immediately, give it some time or maybe I will get around to answering it myself when I get a chance to post on the GNU mailing list or somewhere else. I have read what you posted, and the question is fine. I'm not going to come up with hypothetical examples when the question is entirely precise and because the questions relate to an actual implementation. – MetaChrome Dec 04 '13 at 14:17
  • 3
    @MetaChrome We frequently find that *users*, who **don't know** what they're doing, ask "How do I ABC?", but don't actually want to do ABC, they want XYZ, but it's not what they ask for because they **don't know**. Hence MadHatter's line of questions. Also, getting negative about your interaction with [SF] *really* doesn't make anyone want to help you. We don't owe you *anything*, keep that in mind when your *asking* for help. – Chris S Dec 05 '13 at 15:23
  • Anyway, I'm 100% fine with the meta and I'm 100% fine with the resolution to this question though I think think this comment thread was overzealous on both parties parts. Truthfully, I just didn't understand the meta of this exchange site and now that I do I have a better understanding of the inquiries. – MetaChrome Dec 05 '13 at 16:18

1 Answers1

10

The Unix default permissions for a newly created file are 0666.
The Unix default permissions for a newly created directory are 0777.

If you do not want the default base permissions set an appropriate umask value.
The only thing you can't easily do with umask is create a file which is by default executable (which, by simple common sense, is something you should NOT want to do anyway. Making a file executable should be a conscious choice, not the default behavior.)

If you don't like the default ACL behavior you can change that with setfacl.
Aside from the fact that the default ACL typically mirrors the Unix permissions, ACLs and Unix Permissions are generally independent of each other.

The base permissions have been as described above since the 1960s (when the world was a kinder, gentler place and security wasn't quite so much of a concern - giving everyone on the system the ability to work on your files can be a Good Thing on a closed system of researchers who are all collaborating).

Nobody is going to change that default in a production operating system, and you should not change it either. If you elect to do so anyway it's relatively simple as far as kernel changes go: edit the kernel code and change the default, then rebuild and install your custom kernel.

Implementing such a change (what file to edit, what to change) is left as an exercise for the reader.
Bluntly this is a situation where if you can't figure out how to make the change you shouldn't try.
Know your limitations, and hire a kernel hacker if you need one.

voretaq7
  • 79,879
  • 17
  • 130
  • 214