View previous topic :: View next topic |
Author |
Message |
dE_logics Advocate
Joined: 02 Jan 2009 Posts: 2253 Location: $TERM
|
Posted: Fri Oct 05, 2012 5:39 pm Post subject: The trouble with umask 137. |
|
|
My idea was to remove the executable bit when creating new files or downloading something; it did happen by default, but I didn't understand why. My .bashrc profile said I had umask 027, so did the umask command say, but still the files created didn't have executable permissions.
So to ensure the settings, I set this umask to /etc/profile and ~/.bashrc and god dammed, did I run into BIG trouble.
It took me 2 hours to diagnose the problem and I realized that the directories that kdm/kde created didn't have the exec flag set; so it couldn't be opened; the root of the problem was dbus, in which the .dbus/session-bus dir couldn't be opened, as a result, failed login. Now I know why kdm was spitting out dbus issues, but dbus was running fine from the init scripts.
Surprisingly today I set the same settings (umask 133) on my Debian systems, and they made directories with the x bit set There was no failed login, and absolutely no problems.
So today I decided to clear this up -- What if I want to tweak the environment to set up different permissions on directories and files?
I remember placing this question before, but not sure where. _________________ My blog |
|
Back to top |
|
|
jrussia Tux's lil' helper
Joined: 29 Aug 2012 Posts: 89 Location: Chicago
|
Posted: Fri Oct 05, 2012 6:56 pm Post subject: |
|
|
Files are created without the executable bit by default, which is a security measure. Because of this, you can control both files and directories using umask, because you don't need to consider the executable bit for files that are not directories.
For example,
umask 026 will have the resulting permissions rw-r----- for files and rwxr-x--x for directories,
umask 027 will have the resulting permissions rw-r----- for files and rwxr-x--- for directories.
Note there is no difference to files because the executable bit was removed by default.
Therefore the problem with umask 137 or 133, as you have noticed, is that it removes the executable bit for directories for the owner.
I'm not sure why it worked in Debian - I guess either it has additional safeguards to prevent this, or you didn't configure it the way you thought you did.
To answer your other question, I don't think you can set perms for files and directories differently with umask.
Last edited by jrussia on Sat Oct 06, 2012 6:03 pm; edited 1 time in total |
|
Back to top |
|
|
dE_logics Advocate
Joined: 02 Jan 2009 Posts: 2253 Location: $TERM
|
Posted: Sat Oct 06, 2012 12:39 pm Post subject: |
|
|
Humm. Thanks for clarifying that.
However, I did check the umask in debian, it was 133. _________________ My blog |
|
Back to top |
|
|
PaulBredbury Watchman
Joined: 14 Jul 2005 Posts: 7310
|
Posted: Sat Oct 06, 2012 1:48 pm Post subject: |
|
|
Do you have /etc/pam.d/login specifying the umask, e.g.:
Code: | session optional pam_umask.so umask=0022 |
|
|
Back to top |
|
|
dE_logics Advocate
Joined: 02 Jan 2009 Posts: 2253 Location: $TERM
|
Posted: Sun Oct 07, 2012 7:16 am Post subject: |
|
|
PaulBredbury wrote: | Do you have /etc/pam.d/login specifying the umask, e.g.:
Code: | session optional pam_umask.so umask=0022 |
|
No. _________________ My blog |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|