Re: Howto NFS shared writable space
Colin Watson wrote: On Mon, Mar 10, 2003 at 10:22:02PM +0100, R?mi Letot wrote: Now why is debian's default 022 if 02 is safe ? Mostly because 002 is *not* safe if you don't go with the one-user-per-group thing. Let me guess at another reason. Because programs like postfix, exim, sendmail, ssh, gpg, etc. check that files $HOME are not group writable by default. If those programs are not all modified to allow group writability then they refuse to honor user .forward files, .ssh/ files, etc. User's need to remember to chmod go-w those specifically. Which is yet more that the user needs to know and if they don't the have problems getting software to work. (BTW I don't know if Debian's versions of those programs allow group writability or not.) Both debian.org machines and my workplace use a single group for all users (which I happen to think is a pain, but hey); My work place too. The legacy of 15 years. Everyone is a 'user'. And now we also have shared groups too. A mixed environment confusing to all. Sigh. the failure mode where somebody sets that up without realizing that the default umask needs to be 022 is worse than the failure mode where people end up with files that need to be group-writeable but aren't, so Debian goes with the more generally safe default. And probably the 90% case anyway. I suspect that most people running GNU/Linux are doing so on standalone systems where they are not working with other people on shared files. For example, almost all software tools are designed to work in private sandboxes with cvs interfacing to and controlling the shared area. Therefore few users really ever need a way to work on shared files. Those that do need it can set it up. But I have wondered why umask is in the /etc/skel/* files redundantly with /etc/profile. That propagates the changes into the user's profiles which once embedded are a much more delicate problem to change. Bob pgp0.pgp Description: PGP signature
Re: Howto NFS shared writable space
Hei! Ühel ilusal päeval [10-03-2003 13:31] kirjutas Rémi Letot: Hi all, I'm trying to setup a shared disk space with NFS. Till then, no problem. But I want that people belonging to a specific group can write to it, and modify every file in it. So I made the exported directory belong to the group, put the sticky bit on it, so every file created in it belongs to the group. No problem. But the permissions on newly created files are g+r, and I need g+rw so that everyone belonging to the group can manipulate those files without problem. Is there a way to set this up? I have searched a lot, and can't find a way. I can't believe that such a simple setup is not doable. I had same problem as you had. My solution was to run a script from crontab to periodically chmod and chown those files. Example: #!/bin/bash chown -R fileowner:sharedgroup /shared/dir/* chmod -R g+w /shared/dir/* chmod -R o-w /shared/dir/* Greetings, Juhan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Howto NFS shared writable space
On Mon, Mar 10, 2003 at 12:12:29PM +0100, R?mi Letot wrote: I'm trying to setup a shared disk space with NFS. Till then, no problem. But I want that people belonging to a specific group can write to it, and modify every file in it. So I made the exported directory belong to the group, put the sticky bit on it, so every file created in it belongs to the group. No problem. But the permissions on newly created files are g+r, and I need g+rw so that everyone belonging to the group can manipulate those files without problem. People creating new files in group-writeable locations should use 'umask 2' first. If you have a one-group-per-user setup (as is standard on Debian systems), then they can just set 'umask 2' all the time safely. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Howto NFS shared writable space
Colin Watson wrote: People creating new files in group-writeable locations should use 'umask 2' first. If you have a one-group-per-user setup (as is standard on Debian systems), then they can just set 'umask 2' all the time safely. Colin's answer is, as always, right on target. But I wanted to add some hints that perhaps would not be so obvious. The default /etc/profile contains 'umask 022'. You probably want to change that to the following instead. umask 022 if [ $(id -u) -ge 1000 ]; then umask 02 fi Or possibly the more careful: umask 022 if [ $(id -u) = $(id -g) -a $(id -u) -ge 1000 ]; then umask 02 fi Which tests that your group is really the same as your user id. In which case we know that one-group-per-user is set up as standard. But it catches it in the case that it changes. And that you are a user in user space at or above 1000 and not a system user below that range. Then in /etc/skel/.bash_profile you need to remove the umask setting entirely. Or change it to 02. I recommend removing it entirely there and letting the system /etc/profile control it when possible. Also change the other dot files in the skeleton directory for other shells. Or delete them if you don't use them. Having done the above you are set up for new users that you add after changing that line. But previously added users have already gotten the old skeleton bash_profile file in their home directory. You will need to handle those users in some way. Probably by editing those files and deleting the umask line from them. But being user files you need to tread carefully. Many users take offense at the administrator touching user files. And they may have already customized it. Bob pgp0.pgp Description: PGP signature
Re: Howto NFS shared writable space
Colin Watson [EMAIL PROTECTED] writes: On Mon, Mar 10, 2003 at 12:12:29PM +0100, R?mi Letot wrote: I'm trying to setup a shared disk space with NFS. Till then, no problem. But I want that people belonging to a specific group can write to it, and modify every file in it. So I made the exported directory belong to the group, put the sticky bit on it, so every file created in it belongs to the group. No problem. But the permissions on newly created files are g+r, and I need g+rw so that everyone belonging to the group can manipulate those files without problem. People creating new files in group-writeable locations should use 'umask 2' first. If you have a one-group-per-user setup (as is standard on Debian systems), then they can just set 'umask 2' all the time safely. I considered that option, but was somehow uncomfortable about it... Maybe the fact that debian's default is 022 made me cautious, or I wanted to know if there was an alternative before changing a system wide default. It feels strange to modify a system's default config just for one directory, but it seems I have no other choice (except creating a fat32 partition and mounting it with the right parameters... :-) Now why is debian's default 022 if 02 is safe ? Thanks for your answer, -- Rémi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Howto NFS shared writable space
[EMAIL PROTECTED] (Bob Proulx) writes: Colin Watson wrote: People creating new files in group-writeable locations should use 'umask 2' first. If you have a one-group-per-user setup (as is standard on Debian systems), then they can just set 'umask 2' all the time safely. Colin's answer is, as always, right on target. But I wanted to add some hints that perhaps would not be so obvious. Great idea, and thanks for the explanations :-) couic -- Rémi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Howto NFS shared writable space
On Mon, Mar 10, 2003 at 10:22:02PM +0100, R?mi Letot wrote: Now why is debian's default 022 if 02 is safe ? Mostly because 002 is *not* safe if you don't go with the one-user-per-group thing. Both debian.org machines and my workplace use a single group for all users (which I happen to think is a pain, but hey); the failure mode where somebody sets that up without realizing that the default umask needs to be 022 is worse than the failure mode where people end up with files that need to be group-writeable but aren't, so Debian goes with the more generally safe default. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]