glitch83
August 16th, 2009, 02:18 PM
I recently came across the idea of umask for a shared directory and frankly I disagree with the design of the system in general and hopefully someone can describe a) why it is the case and b) how I can achieve what I want.
umask was designed to restrict permissions on file creation as a safe way of working in groups in shared directories.(it seems) I also find that the umask is set (I have found) in two major places; 1) the umask command and 2) the fstab. For the fstab - this makes sense, at a filesystem level, we should be able to set global umask and have it work globally regardless of the child process. But the umask command doesn't make sense to me - its affects only exist for the lifetime of the process. This means that most people hack their way through umask using the bashrc or profile etc. Sometimes we get lucky and scp and other siblings pay attention to our particular preferences file but what happens if a user decides to use korn or heaven forbid scsh? Would their umask requests be honored?
The default case and the common use of umask
It seems like the default settings for umask are 022 which means that files I create are not writable by the group. One of the most common reasons people come across umask are to give users write access to fellow group members on file creation. This is all well and good but that means that for the sysadmin - every new user that gets added to that group needs to get a "umask 002 /dir/" in their bashrc... that just seems counterintuitive. Shouldn't there be a more persistent solution? It seems like that kind of access should exist - I mean the functionality is there if fstab can do it.. On the other hand, hacking the fstab to do a umask on a filesystem seems like the way to go but if you are on a more flexible system - you don't want to repartition and re-umask everytime the managers ask for something new.
I guess my main question here is that chmod/chgrp are such wonderful tools, it seems like umask should have similar functionality (be more persistent). What say you? Have I solved my problem wrong (adding umask to the bashrc)? Is there a better solution? Maybe a more persistent tool I have missed?
Thanks :-)
umask was designed to restrict permissions on file creation as a safe way of working in groups in shared directories.(it seems) I also find that the umask is set (I have found) in two major places; 1) the umask command and 2) the fstab. For the fstab - this makes sense, at a filesystem level, we should be able to set global umask and have it work globally regardless of the child process. But the umask command doesn't make sense to me - its affects only exist for the lifetime of the process. This means that most people hack their way through umask using the bashrc or profile etc. Sometimes we get lucky and scp and other siblings pay attention to our particular preferences file but what happens if a user decides to use korn or heaven forbid scsh? Would their umask requests be honored?
The default case and the common use of umask
It seems like the default settings for umask are 022 which means that files I create are not writable by the group. One of the most common reasons people come across umask are to give users write access to fellow group members on file creation. This is all well and good but that means that for the sysadmin - every new user that gets added to that group needs to get a "umask 002 /dir/" in their bashrc... that just seems counterintuitive. Shouldn't there be a more persistent solution? It seems like that kind of access should exist - I mean the functionality is there if fstab can do it.. On the other hand, hacking the fstab to do a umask on a filesystem seems like the way to go but if you are on a more flexible system - you don't want to repartition and re-umask everytime the managers ask for something new.
I guess my main question here is that chmod/chgrp are such wonderful tools, it seems like umask should have similar functionality (be more persistent). What say you? Have I solved my problem wrong (adding umask to the bashrc)? Is there a better solution? Maybe a more persistent tool I have missed?
Thanks :-)