When I create a new file/folder in a ext4 data partition, it has permissions:
owner: rwx
group: r
other: r
I would like to change this default to:
owner: rwx
group: rw
other: -
I tried changing fstab, but umask and guid are not supported mount options for ext4. What can I do?
Note: I know I can do a chmod, but I don’t want to do this again and again for every new file I create.
Did a quick search, and figured this out, somebody stop me if I’m way off:
To change default file permissions to what you’re asking, this line should be added to /etc/pam.d/login
session optional pam_umask.so umask=0017
If I figured this out correctly, umask’s numbers works opposite of chmod, so the two first zeros keeps all permissions for root and owner, the following one subtracts execute rights from group permissions, and the last 7 takes away all rights to other users.
Give it a go, if it doesn’t work it’s fairly easy to remove again.
The tradition method would be to give a “umask” command in your “.profile” (in your home directory)
umask 017
So I tested this out, solely out of curiosity.
Added this line to /etc/pam.d/login
session optional pam_umask.so umask=017
Then changed the value of umask in /etc/login.defs
umask 017
Rebooted, checked file permissions afterwards
umask -S
u=rwx,g=rw,o=
Seems to be granted the way OP wanted.
Guessing this would be the way to globally change the default user permissions, the method shown in the post above would be user specific, which probably is what you’re looking for.
Going to change mine back to 022 now 
Of course changing something in a system configuration (done by root and in this case within* /etc*) is system wide.
Doing it in the profile of a user (can of course be done by the user) is user wide (that is not that “wide” at all ;)).
It is not clear what the OP wants (he does not explicitly state he askes this as end-user (for his own security) or as system manager (as a system wide policy), but the fact that he talks about an end-user tool like Dolphin lets me think the first one is the case. Thus both answers may be valid and the OP has to chose one (or both).
The system manager has also to be aware of the fact that a system wide policy can be overuled by the user in this case.
(And of course, since allready more then 30 year the first thing after I got a new userid on any system was to add
umask 077
to my profile).
Many thanks for the replies! 4 years of running linux and still learning new stuff:)
Maybe I can teach you something as well;). Looks like umask is deprecated in /etc/login.defs.
New value is in /etc/default/useradd. Could it be that for a global change you only have to change the value in /etc/default/useradd and not change /etc/pam.d/login?
I also wonder: if you both set a different umask in /etc and in your .profile, will it use the umask of the .profile?
As your* .profile* or .bashrc or the like files are excecuted at login, the statements there are executed. Thus when you have an umask statement there, it will be executed and thus when you get your first prompt after login that is the umask that is valid. You can of course at any moment change that by typing a different umask statement.
Every time you give an umask statement the umask is changed (maybe to the same value it had). Thus it is easy to determine which one is valid: the last one.
You should be aware of the fact that the umask commando is a built-in in the shell and uses the umask() function. (homework: why is it useles to have it as a separte program, I am willing to give the answer when you have realy thought about that). Also any other program can have a buit-in call to the umask() function and thus can overrule any umask you may have set.
And because the umask itself is part of the process environment it will be inherited by all child processes. Thus when your umask is 057 and you start program a and then change your umask to *077 *and then start program b, program a will use a different umask then program b when it comes to creating new files.
Also because you have an umask immediatly after login (either some default or the one you put yourself in your .profile) in the GUI, all processes started in that session will inherit that umask, including your dolphin. That is why dolphin uses this umask when it creates a new file on your whish.
Note that this also means that your original question (to change the umask of the dolphin processes you run as an end-user) is not realy answered as setting the wanted umask in your .profile means that it is valid for all the programs running in your session, not just dolphin. But as usual we do a lot of assumptions when answeriing questions and we assumed here that you wanted an umask for all programs in your sessions. Some even assumed that you wanted that umask for all programs, for all sessions, for all users (but you are now at the point where it is clear to you that the individual users can nullify this easily).
And to break a long post into pieces…
The values defined in places like /etc/default/useradd are used at the creation of a user. That means for the umask case, that the umask statement in .profiile is created with this value. When you change that value in /etc/default/useradd, it does of course not change the umask statements in the .profile of existing users. It is only for newly created users.
Again I point to the fact that every user can of course change his .profile to his whish and thus change the umask he wants to use during his sessions. And that every user can type an umask statement or use it in his scripts at will. Thus the security officer that asks system managers to create users with a certain restrictive umask and then leans back thinking that he pluged a hole, may only do this when none of the users ever had a Unix/Linux course and is in general dumb.
See here: SDB:Set UMASK - openSUSE
The correct* way to do it system-wide is (as root): pam-config -a --umask --umask-umask=0027
*correct as in I was told this by an opensuse developer when I filed a bug report about the setting in /etc/login.defs not working (it has indeed been deprecated).
On 06/29/2011 11:06 PM, tk83 wrote:
>
> The correct* way to do it system-wide is (as root): pam-config -a
> --umask --umask-umask=0027
i won’t/can’t argue the “correct” way to do it system wide (this looks
good to me), but wonder if i really want everyone being able to read
everyone else’s files? (as the 002n allows)
but, i also wonder if the machine would catch on fire or melt if i used
pam-config to set 0077…
wouldn’t that make everyone stay out of my files…but, would it break
anything??
I think that’s more to do with the Opensuse default of adding all non-system users to the ‘users’ group by default. Other distributions (Fedora, RHEL + derivaties, Mandriva) create a group for each user automatically when they’re added with useradd or the respective GUI tools. This is for security so I’ve always wondered whay Opensuse doesn’t do it.
won’t/can’t argue the “correct” way to do it system wide (this looks
good to me), but wonder if i really want everyone being able to read
everyone else’s files? (as the 002n allows)
I guess that most of us thought the value being an example. Everybody will fill in a value of his/her own choice according to what one needs.
And an umask of 027 does NOT allow everybody to read a file. It will on creation of a file mask off the write bit for group and ALL bits for others. Thus when the owner does not change those access bits later, only the user and members of his group can read the file, others can not!
but, i also wonder if the machine would catch on fire or melt if i used
pam-config to set 0077…
wouldn’t that make everyone stay out of my files…but, would it break
anything??
The PAM value would set an umask value for some processes (not all programs are PAM aware) and those programs will then create files with access bits according to the access bits the program thinks fit for that file, masked with the umask (as defined in PAM). When this results in setting no *rwx *bits for group and others, then the user only can rwx the file. As said earlier, I did this allways (being an ordinary user I did this by setting umask in my .profile).
But yes, it can break something. When user a creates files and assumes that user b (not in his group) can read them because the default umask allows this and then from day X the system manager changes to a more restrictive value where the others bits are masked off, this user a can then claim that his way of working is broken. He can of course adapt by doing a chmod o+r a.s.a.p. after creation, but he may be upset (especialy when not informed of the upcoming change in time).
I do not know much of PAM (just read a bit around the last half an hour). But programs must be PAM aware (meaning that calls to the PAM libraries must be coded in it). Thus setting this value in PAM may influence Dolphin ( I do not know, but I guess), but I doubt it will influence simple programs like touch.
A question raising to me is, if I have set a very restrictiv umask for my sessions (like 077) and the system manager put a less restrictive one (like 027) in PAM, what would a PAM aware program do? Create with my mask or with the PAM mask. The latter option would make me very angry of course.
And last, about “the system on fire”. I guess most system tools will not be PAM aware. Those tools know in general very well how access bits must be set for every individual file they create. It might even be a good idea for those tools to set the access bits explicitly to the correct values after creating the file (I do this in several scripts). BTW, it could even be true that PAM will not change the umask to the PAM value when it is a root process.
I don’t think this is how it works. All logins on an Opensuse system go through PAM and (among other things) PAM sets the umask value. So neither touch, Dolphin nor any other application needs to have PAM support coded in to be affected by the umask value that PAM sets.
I tested this by changing my umask using PAM, logging out and back in and then using touch and Dolphin. Both used the new umask set by PAM and the umask command reported it, meaning PAM’s setting is seen from the whole session from the point of login onwards.
A question raising to me is, if I have set a very restrictiv umask for my sessions (like 077) and the system manager put a less restrictive one (like 027) in PAM, what would a PAM aware program do? Create with my mask or with the PAM mask. The latter option would make me very angry of course.
I just tested this and there’s no need to get angry 
The umask value that PAM sets can be overridden by simply running ‘umask XXXX’ in a terminal, or of course putting that in your .bash_profile, .profile or whatever.
tk83 wrote:
> I think that’s more to do with the Opensuse default of adding all
> non-system users to the ‘users’ group by default. Other distributions
> (Fedora, RHEL + derivaties, Mandriva) create a group for each user
> automatically when they’re added with useradd or the respective GUI
> tools. This is for security so I’ve always wondered whay Opensuse
> doesn’t do it.
The opensuse way is just the traditional Unix way.
One could argue that the idea of a group per user is redundant; you
could instead just set all group permissions to 0. It doesn’t really
matter what the default is; if you’re concerned about security, you’ll
want to tweak things to your own requirements anyway.
Ok then when PAM does not influence individual PAM aware programs in the umask case, then we are at the simple construct as it was allways. It gets some velue at login (of course, there isn’t such a thing as “no value” for umask). That value is nowadays determined by a setting in PAM where it was earlier in other places.
After login we get the central profile (/etc/profile) where we can still change it for all logins, but it is not recommended to do.
After that we get the users .profile where (s)he can set what (s)he thinks fit (my 077 for example).
After that the users can of course change again for all the individual processes he wants to run.
And there is no difference between Dolphin and touch and thus dolphin answers to all th same laws we had in Unix/Linux for forty years:
. the system manager sets centraly an umask value as a default** suggestion/service** for users when they log in;
. every user can change this to her/his whim and thus stays responsible for the protection of her/his own files (do not blame the system manager for the umask set at login, change it yourself).
BTW I read the SDB you linked to. I am complete at loss reading the part about “Alter the UMASK value applied to Home Directories of new Users”. I found it in YaST, but the explanation there does not enlighten me. I fail to see what is ment there. How ca you “apply” a umask value to a directory? An umask exists in the environment of a process and nowhere else.
I guess the author of the SDB does not know either, else he would have given an explanation there instead of simply copying the text he found in YaST.
Exactly, it works like it should. The only thing I’d say is don’t change it in /etc/profile - use PAM if you want to change the system-wide setting for new logins.
as I said there “but it is not recommended to do.”
I still guess that the OP of this thread (long time ago 
) wanted this as his user and not system wide (but he maybe the only user until nnow on his system and he may thus think that that is the same, but it isn’t). Andthus he should change his .profile and not run the PAM statment as root. But his mileage may vary.
A bit off topic. I was security manager of some Unix systems (different flavors) in a bigger company. There were off course some centraly devised rules how to go for a secure system. One of those was a restrictive centraly set umask. I never got the message down to them that such an umask can be changed very easy by every user with the slightest bit of Unix knowledge and thus isn’t realy a security rule, but only a bit of a guideline to the user. And you can’t realy check him. You only can check if the files he owns have to much access bits set.
This setting controls what permissions a user’s home directory will have when first created by useradd, since for whatever reason useradd has it’s own ‘–umask’ parameter. Don’t ask me why useradd doesn’t just use the system umask value
I am the author of that SDB, I’ve re-written it to make it a bit clearer: SDB:Set UMASK - openSUSE