[RndTbl] How does umask really work?

[Gilles Detillieux]

On Thursday, Feb 10, 2005, at 09:13 CST, John Lange wrote:
> On Thu, 2005-02-10 at 07:57, Sean A. Walberg wrote:
> >  
> > > IMHO there should be a kernel setting for this (
> > > /proc/sys/fs/filecreatemode /proc/sys/fs/dircreatemode seems logical).
> > 
> > Interesting idea, but by the time it gets to the kernel, it's really not 
> > aware if the mode it's getting is a default or something that you put in 
> > explicitly.  It just takes the number it gets, applies the umask, and 
> > moves on.
> 
> Actually, after further thought, since umask is built into bash and has
> nothing to do with the kernel it makes little sense to have a kernel
> setting for this. Rather it should be a bash environment variable.

No, not quite.  There's a umask command that's built into the shell,
which just runs the umask() sytem call, to set the shell process's
umask in the kernel.  It's the kernel that does the eventual umask bit
twiddling, not bash.  The umask you set in the shell is also inherited
by processes that the shell runs, and if these processes run programs
that create files, the umask will still be used to turn off permission
bits in those files' modes.

...
> > So, to summarize:
> > 
> > - umask works more or less like you thought it did
> > - the reason the file was -x was because whatever application opened the 
> > file wanted it that way, it had nothing to do with the umask
> 
> Ok, that all makes perfect sense. The umask is applied against whatever
> mode the creating program requested.
> 
> So the only remaining question is how do you get files created by bash
> (such as "echo > foo") to be executable by default? This is where it
> would be handy to have a bash environment variable that specifies your
> desired default mode.

No, the other remaining question is why you think whatever "foo" the
shell spits out to a file should be executable by default?  One would
hope that a bit of thought would go into the creation of an executable
file, whether a binary or a script.  Why make this the default, when the
majority of regular files on a file system don't contain executable code?

On Thursday, Feb 10, 2005, at 09:26 CST, John Lange wrote:
> On Thu, 2005-02-10 at 09:16, Gilles Detillieux wrote:
> >   When you create executable text files, i.e. scripts (shell,
> > awk, perl, etc.), then you can easily add execute permission with chmod
> > +x, but you'd only do that if you really want them to be run as
> > commands.  Why would you want execute permission on by default for all
> > regular files?
> 
> Good point. I don't think you normally would. I just think it should be
> possible especially since all the tools are already there.
> 
> If the default for created files was 777, then a umask of 133 would
> still create files with 644 which is exactly what is being done today
> with the added benefit of being able to set your umask to 022 and having
> files created with 755 should you have a need for that.
> 
> This just makes more sense to me than the sort of half implementation of
> user controlled default modes which is bash/umask today.

But a umask of 133 would turn off execute (i.e. search or traversal)
permission on new directories by default.  So, either you're stuck
manually turning off execute permission on the majority of regular files
you create, or you're stuck manually turning on execute permission on
all the directories you create.  This makes more sense that having to
manually chmod the few executable script files you're likely to create,
after thinking about whether the code really is ready to execute?

-- 
Gilles R. Detillieux              E-mail: <grdetil at scrc.umanitoba.ca>
Spinal Cord Research Centre       WWW:    http://www.scrc.umanitoba.ca/
Dept. Physiology, U. of Manitoba  Winnipeg, MB  R3E 3J7  (Canada)