The documentation and examples on umask state that you provide a mask that is subtracted from rwx (777) access to generate a default access for newly created files.
It clearly doesn't work this way.
If you have a umask of 022, newly created files are rw-r--r-- (644). It should be rwxr-xr-x (755). The umask is acting like its 033 and indeed changing it to 033 has no effect on newly created files.
However, umask effects directories differently. umask 022 will create directories as expected (as 755), and umask 033 will create them as 644.
So how do you set a umask that will create files as 755?
I think that it subtracts the umask value from the "default" file mask, not "777". The default is probably 666 (rw-rw-rw-), so a umask of 022 would indeed produce 644. There is a way to set the "default" file mask, but that I don't know.
John Lange wrote:
The documentation and examples on umask state that you provide a mask that is subtracted from rwx (777) access to generate a default access for newly created files.
It clearly doesn't work this way.
If you have a umask of 022, newly created files are rw-r--r-- (644). It should be rwxr-xr-x (755). The umask is acting like its 033 and indeed changing it to 033 has no effect on newly created files.
However, umask effects directories differently. umask 022 will create directories as expected (as 755), and umask 033 will create them as 644.
So how do you set a umask that will create files as 755?
John Lange wrote:
The documentation and examples on umask state that you provide a mask that is subtracted from rwx (777) access to generate a default access for newly created files.
It clearly doesn't work this way.
If you have a umask of 022, newly created files are rw-r--r-- (644). It should be rwxr-xr-x (755). The umask is acting like its 033 and indeed changing it to 033 has no effect on newly created files.
It depends on what specification is used by the program that is creating the file. I think the default for most programs is to not set the x flag.
On second thought (and after checking one book on bash), there may not be a "default". If a text editor tries to create a file with permissions 666 and umask is 022, then it will be created with 644 instead. So it seems to depend on the process creating the file. Gilbert confirms this.
John Lange wrote:
The documentation and examples on umask state that you provide a mask that is subtracted from rwx (777) access to generate a default access for newly created files.
It clearly doesn't work this way.
If you have a umask of 022, newly created files are rw-r--r-- (644). It should be rwxr-xr-x (755). The umask is acting like its 033 and indeed changing it to 033 has no effect on newly created files.
However, umask effects directories differently. umask 022 will create directories as expected (as 755), and umask 033 will create them as 644.
So how do you set a umask that will create files as 755?
From the umask(2) man page:
The umask is used by open(2) to set initial file permissions on a newly-created file. Specifically, permissions in the umask are turned off from the mode argument to open(2) (so, for example, the common umask default value of 022 results in new files being created with per-missions 0666 & ~022 = 0644 = rw-r--r-- in the usual case where the mode is specified as 0666).
And that takes us to open(2):
int open(const char *pathname, int flags, mode_t mode); ... The argument mode specifies the permissions to use in case a new file is created. It is modified by the process's umask in the usual way: the permissions of the created file are (mode & ~umask). Note that this mode only applies to future accesses of the newly created file; the open call that creates a read-only file may well return a read/write file descriptor.
So, it would stand that the umask is used within the kernel at file creation time. If you poke around fs/namei.c in the kernel source, you can see how sys_mknod() uses this value to figure out the actual mode of the file. You'd have to dig into glibc to find where the initial value comes from. ISTR that Bill was on the right track -- directories and files start off with different modes for the umask calculation, directories are 777 and files 666.
Sean
On Wed, 9 Feb 2005, Kevin McGregor wrote:
On second thought (and after checking one book on bash), there may not be a "default". If a text editor tries to create a file with permissions 666 and umask is 022, then it will be created with 644 instead. So it seems to depend on the process creating the file. Gilbert confirms this.
John Lange wrote:
The documentation and examples on umask state that you provide a mask that is subtracted from rwx (777) access to generate a default access for newly created files.
It clearly doesn't work this way.
If you have a umask of 022, newly created files are rw-r--r-- (644). It should be rwxr-xr-x (755). The umask is acting like its 033 and indeed changing it to 033 has no effect on newly created files.
However, umask effects directories differently. umask 022 will create directories as expected (as 755), and umask 033 will create them as 644.
So how do you set a umask that will create files as 755?
That is very interesting.
So the bottom line is, you can not set a default create mode for files to be 755 since the mode is implemented in each individual program.
The best you can do is set modes that can NOT be created by default.
IMHO there should be a kernel setting for this ( /proc/sys/fs/filecreatemode /proc/sys/fs/dircreatemode seems logical).
But of course a LOT of programs would have to be changed to take advantage of that.
John
On Wed, 2005-02-09 at 21:14, Sean A. Walberg wrote:
From the umask(2) man page:
The umask is used by open(2) to set initial file permissions on a newly-created file. Specifically, permissions in the umask are turned off from the mode argument to open(2) (so, for example, the common umask default value of 022 results in new files being created with per-missions 0666 & ~022 = 0644 = rw-r--r-- in the usual case where the mode is specified as 0666).
And that takes us to open(2):
int open(const char *pathname, int flags, mode_t mode); ... The argument mode specifies the permissions to use in case a new file is created. It is modified by the process's umask in the usual way: the permissions of the created file are (mode & ~umask). Note that this mode only applies to future accesses of the newly created file; the open call that creates a read-only file may well return a read/write file descriptor.
So, it would stand that the umask is used within the kernel at file creation time. If you poke around fs/namei.c in the kernel source, you can see how sys_mknod() uses this value to figure out the actual mode of the file. You'd have to dig into glibc to find where the initial value comes from. ISTR that Bill was on the right track -- directories and files start off with different modes for the umask calculation, directories are 777 and files 666.
Sean
On Wed, 9 Feb 2005, Kevin McGregor wrote:
On second thought (and after checking one book on bash), there may not be a "default". If a text editor tries to create a file with permissions 666 and umask is 022, then it will be created with 644 instead. So it seems to depend on the process creating the file. Gilbert confirms this.
John Lange wrote:
The documentation and examples on umask state that you provide a mask that is subtracted from rwx (777) access to generate a default access for newly created files.
It clearly doesn't work this way.
If you have a umask of 022, newly created files are rw-r--r-- (644). It should be rwxr-xr-x (755). The umask is acting like its 033 and indeed changing it to 033 has no effect on newly created files.
However, umask effects directories differently. umask 022 will create directories as expected (as 755), and umask 033 will create them as 644.
So how do you set a umask that will create files as 755?
On Wed, 9 Feb 2005, John Lange wrote:
So the bottom line is, you can not set a default create mode for files to be 755 since the mode is implemented in each individual program.
Not quite. Each program can specify the mode to create a file with when it calls open() or creat(). The kernel takes this mode and applies the umask to get the actual mode. If the program opened the file with a mode of 777 and the umask were 022, you'd get 755 as in my example below.
The best you can do is set modes that can NOT be created by default.
That is the umask, yes. However there seem to be other things at play that turn off additional bits.
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.
Consider the following program:
#include <sys/types.h> #include <sys/stat.h> #include <fcntl.h>
int main(void) {
int fd;
fd = open("withmode", O_CREAT, S_IRWXO | S_IRWXG | S_IRWXU); close(fd); fd = open("withoutmode", O_CREAT); close(fd); }
It opens two files, specifying a 777 mode for the first, and none for the second:
[sean@sergeant sean]$ gcc open.c -o open [sean@sergeant sean]$ umask 0022 [sean@sergeant sean]$ ./open [sean@sergeant sean]$ ls -l with*mode -rwxr-xr-x 1 sean users 0 Feb 10 07:48 withmode -rwxr-xr-x 1 sean users 0 Feb 10 07:48 withoutmode
Interestingly enough, they're both 755!
However if I do a simple "echo > foo", I get a mode of 644.
[sean@sergeant sean]$ strace bash -c "echo > foo" [sean@sergeant tmp]$ ls -l foo -rw-r--r-- 1 sean users 1 Feb 10 07:53 foo
Looking at the output of strace...
open("foo", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
Meaning bash explicitly opened the file with a mode of 666, which after my umask of 022 was applied, resulted in a file mode of 644.
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
Sean
On Wed, 2005-02-09 at 21:14, Sean A. Walberg wrote:
From the umask(2) man page:
The umask is used by open(2) to set initial file permissions on a newly-created file. Specifically, permissions in the umask are turned off from the mode argument to open(2) (so, for example, the common umask default value of 022 results in new files being created with per-missions 0666 & ~022 = 0644 = rw-r--r-- in the usual case where the mode is specified as 0666).
And that takes us to open(2):
int open(const char *pathname, int flags, mode_t mode); ... The argument mode specifies the permissions to use in case a new file is created. It is modified by the process's umask in the usual way: the permissions of the created file are (mode & ~umask). Note that this mode only applies to future accesses of the newly created file; the open call that creates a read-only file may well return a read/write file descriptor.
So, it would stand that the umask is used within the kernel at file creation time. If you poke around fs/namei.c in the kernel source, you can see how sys_mknod() uses this value to figure out the actual mode of the file. You'd have to dig into glibc to find where the initial value comes from. ISTR that Bill was on the right track -- directories and files start off with different modes for the umask calculation, directories are 777 and files 666.
Sean
On Wed, 9 Feb 2005, Kevin McGregor wrote:
On second thought (and after checking one book on bash), there may not be a "default". If a text editor tries to create a file with permissions 666 and umask is 022, then it will be created with 644 instead. So it seems to depend on the process creating the file. Gilbert confirms this.
John Lange wrote:
The documentation and examples on umask state that you provide a mask that is subtracted from rwx (777) access to generate a default access for newly created files.
It clearly doesn't work this way.
If you have a umask of 022, newly created files are rw-r--r-- (644). It should be rwxr-xr-x (755). The umask is acting like its 033 and indeed changing it to 033 has no effect on newly created files.
However, umask effects directories differently. umask 022 will create directories as expected (as 755), and umask 033 will create them as 644.
So how do you set a umask that will create files as 755?
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.
Consider the following program:
#include <sys/types.h> #include <sys/stat.h> #include <fcntl.h>
int main(void) {
int fd; fd = open("withmode", O_CREAT, S_IRWXO | S_IRWXG | S_IRWXU); close(fd); fd = open("withoutmode", O_CREAT); close(fd);}
It opens two files, specifying a 777 mode for the first, and none for the second:
[sean@sergeant sean]$ gcc open.c -o open [sean@sergeant sean]$ umask 0022 [sean@sergeant sean]$ ./open [sean@sergeant sean]$ ls -l with*mode -rwxr-xr-x 1 sean users 0 Feb 10 07:48 withmode -rwxr-xr-x 1 sean users 0 Feb 10 07:48 withoutmode
Interestingly enough, they're both 755!
However if I do a simple "echo > foo", I get a mode of 644.
[sean@sergeant sean]$ strace bash -c "echo > foo" [sean@sergeant tmp]$ ls -l foo -rw-r--r-- 1 sean users 1 Feb 10 07:53 foo
Looking at the output of strace...
open("foo", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
Meaning bash explicitly opened the file with a mode of 666, which after my umask of 022 was applied, resulted in a file mode of 644.
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.
John
On Wed, 2005-02-09 at 21:14, Sean A. Walberg wrote:
From the umask(2) man page:
The umask is used by open(2) to set initial file permissions on a newly-created file. Specifically, permissions in the umask are turned off from the mode argument to open(2) (so, for example, the common umask default value of 022 results in new files being created with per-missions 0666 & ~022 = 0644 = rw-r--r-- in the usual case where the mode is specified as 0666).
And that takes us to open(2):
int open(const char *pathname, int flags, mode_t mode); ... The argument mode specifies the permissions to use in case a new file is created. It is modified by the process's umask in the usual way: the permissions of the created file are (mode & ~umask). Note that this mode only applies to future accesses of the newly created file; the open call that creates a read-only file may well return a read/write file descriptor.
So, it would stand that the umask is used within the kernel at file creation time. If you poke around fs/namei.c in the kernel source, you can see how sys_mknod() uses this value to figure out the actual mode of the file. You'd have to dig into glibc to find where the initial value comes from. ISTR that Bill was on the right track -- directories and files start off with different modes for the umask calculation, directories are 777 and files 666.
Sean
On Wed, 9 Feb 2005, Kevin McGregor wrote:
On second thought (and after checking one book on bash), there may not be a "default". If a text editor tries to create a file with permissions 666 and umask is 022, then it will be created with 644 instead. So it seems to depend on the process creating the file. Gilbert confirms this.
John Lange wrote:
The documentation and examples on umask state that you provide a mask that is subtracted from rwx (777) access to generate a default access for newly created files.
It clearly doesn't work this way.
If you have a umask of 022, newly created files are rw-r--r-- (644). It should be rwxr-xr-x (755). The umask is acting like its 033 and indeed changing it to 033 has no effect on newly created files.
However, umask effects directories differently. umask 022 will create directories as expected (as 755), and umask 033 will create them as 644.
So how do you set a umask that will create files as 755?
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?
On Thu, 2005-02-10 at 10:30, Gilles Detillieux wrote:
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?
Of course some thought should go into it but thats not the point. I just don't agree that just because we can't think of a good reason to do it on our system that it shouldn't be possible for anyone.
But a umask of 133 would turn off execute (i.e. search or traversal) permission on new directories by default.
Which is another flaw in umask. It should be:
Umask [ Umask file octal-mask [directory octal-mask]]
(Which is how it is implemented in proftpd)
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.
Wouldn't a default of 700 for directories make the most sense for the majority of users anyhow?
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?
I agree that this method makes more sense given that there is no way to specify file masks and directory masks separately.
On Thu, 10 Feb 2005, John Lange wrote:
Wouldn't a default of 700 for directories make the most sense for the majority of users anyhow?
Not necessarily, since it depends on a lot of other factors. In the user private group scheme, the default directory mode should be 750 so that people in the same group can share and personal directories are effectively 700.
The issue is not with umask, it's in userland. And I'm with Gilles -- bash is behaving in a sane manner, doing things in such a way that 90% of the people are happy. Applications are free to chmod() the inodes after creation, which is what proftpd will be doing.
Sean
On Wednesday, Feb 9, 2005, at 22:18 CST, John Lange wrote:
So the bottom line is, you can not set a default create mode for files to be 755 since the mode is implemented in each individual program.
The best you can do is set modes that can NOT be created by default.
IMHO there should be a kernel setting for this ( /proc/sys/fs/filecreatemode /proc/sys/fs/dircreatemode seems logical).
But of course a LOT of programs would have to be changed to take advantage of that.
This raises the question of what, exactly, would be the advantage of that. Programs tend to turn on the right bits by default for the type of file being created, and I'd be hard pressed to come up with an example of where it would be useful to override that default. Directories have execute permissions turned on by default because it makes sense (execute = traversal for directories). Regular files don't usually have execute permission turned on by default because it doesn't usually make sense, unless they actually contain executable code which you want to run as a command. ld turns on execute permission on binaries after successfully linking them, as they're then ready to execute. 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?
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.
-
Bill Reid -
Gilles Detillieux -
John Lange -
Kevin McGregor -
Sean A. Walberg