On Mon, 2004-10-25 at 09:19 -0700, Paul Lutus wrote:
> 2. To find out what the default permissions are, type:
>
> $ umask -S
>
> Usually the default is "u=rwx,g=rwx,o=rx", but this doesn't mean new files
> are created with their executable bit set.
This shows a umask of 002, which is considered insecure.
The default user account umask on every system I've ever messed with is
022, which prevents the 'group' and 'other' writable flags from being
set. The root account is sometimes set to something else, which I don't
remember. More secure systems set their default umask to 027, which
disallows the 'group' write bit, and *any* 'other' bit (symbolically,
u=rwx,g=rx,o="). I've seen paranoid systems that set their umask to 077,
which disallows *any* 'group' or 'other' bit (ie: "u=rwx,g=,o=").
Note, however, that the umask only comes in to play whenever a file or
folder is *created*; after creation, chmod can be used to change it to
whatever permissions you wish (unless you've got a *truly* paranoid
sysadmin who's modified the system to *always* honor the umask; don't
laugh--I've heard of this happening).
> 3. I don't think you can set "rwx" as a default mode for newly created
> files. AFAIK the executable bit must be explicitly set for those files that
> need it. So, unless I am wrong, your original example permissions are not
> accurate.
Sure you can; all the umask does, essentially, is determine which bits
are *allowed* by default. Whenever you create a file, the utility
creating that file requests a specific bitmask (typically 666 for files;
777 for folders). This requested bitmask is then filtered through the
umask which determines the *actual* bitmask that gets applied to the
file. So all the umask does is specify which permission bits are *not*
allowed to be applied to a file when it is created; or *are* allowed,
depending on how you choose to interpret it.
Check the following link for a more coherent explanation:
http://www.lugod.org/mailinglists/archives/vox-tech/2001-03/msg00039.html
> Do this experiment in a shell:
>
> $ umask 000
>
> $ touch testfilename
>
> $ ls -la testfilename
>
> On my system (FC2), I get:
>
> -rw-rw-rw- 1 user group 0 Oct 25 09:02 testfile
This is because touch requests a bitmask of rw-rw-rw-, or 666, when it
creates a file. Try mkdir, and you'll get rwxrwxrwx instead. What you're
seeing here is the *requested* bitmask, since your umask of 000 isn't
filtering out *any* of the requested bits.
The only reason you don't see execute bits applied to newly created
files is because very few utilities request the execute bit for a newly
created file. If you were to write your own version of touch that
requested a bitmask of rwxrw-r--, or 764, then that's exactly what you'd
get with a umask of 000. On the other hand, with the accepted default
umask of 022, them your resulting bitmask would be rwxr--r--, or 744.
> Even though in principle the provided mask allows all permissions to all
> entities.