Re: Help with UMASK and file/directory permissions on sarge
"intendedacceleration" <intendedacceleration@gmail.com> writes:
> Ah ok, I'm starting to narrow down the problem now. When I login as the
> user, everything works correctly, but when I am root, the umask is
> still wrong and as such the write bit is not set on any files created
> in that directory. I looked in root's ~/.bashrc file and I see that the
> umask is set statically in there.
>
> Sorry for the confusion on my part, i can see why I thought it wasn't
> working correctly now.
>
> My question now is how many places is/can umask be set, and where
> SHOULD it be changed? I can see this quickly becoming a nightmare
> trying to keep straight.
>
> So far I have seen umask in:
> ~/.bash_profile
> ~/.bashrc
> /etc/login.defs
> /etc/profile
> /etc/skel/.bash_profile (I know this is used for a templete for new
> users)
>
> The ~/.bash_profile file references the /etc/login.defs file to make a
> change to the umask. When I change the umask there is seemed to have no
> effect. What is this file used for and when should it be edited? Same
> for /etc/profile? There has to be a "right" and a "wrong" way to do
> this, I just want to make sure I am learning the right way.
>
Sorry to say that, but this issue is a complete mess and there is no
'right way' as far as I can see. But one after the other (I just dug
through this stuff, too):
(1) login.defs is part of the 'login' package; it's setting takes effect
for login sessions at least on the console, but ...
(2) the shell you use still sources profiles, which may override that
setting, as /etc/profile does, which is sourced by bash (man bash)
but may not by other shells; now, for an interesting test, comment
out the umask setting in /etc/profile and log in on the console; if
nothing else overrides umask (.bash_profile, .bash_rc), you'll see
that login.defs really takes effect
(3) now the added complication of graphic logins; what people often
confuses is that the gnome seesion manager gdm doesn't source
.bash_profile so that their settings don't take effect; actually,
gdm has it's own file for user settings, which is ~/.gnomerc; I
currently don't know whether it also sources a global profile somewhere;
also, I don't know about KDE
(4) finally, no matter how hard you try, any user can override your site
wide settings anyway in his profile, and complain afterwards that
some things don't work :)
That's all I can tell so far, i.e. that there definitely isn't a failsafe
method to set umask for all shells, graphic logins and users. I guess all
you can implement is a policy, i.e. set umask e.g. in /etc/profile
and login.defs, then tell your users to exclusively use bash or some other
shell which sources /etc/profile upon login, like ksh, and not override umask
themselves if they want that stuff to work. If they use graphic logins, find
out where to set the environment sidewide for your particular session manager,
and tell users again. Sorry, I know this is frustrating, but I'm afraid I
pretty much depicted the situation as it is. If somebody knows more, please
step in.
Regards, Bruno.
Reply to: