File base permissions are 666, why and is this a configurable value? [closed]
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.
- Can the file base permissions of 666 be changed?
- 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?
- 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.
Solution 1:
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.