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?