public folder file permissions
scott at redboot.biz
Thu Apr 19 03:04:03 BST 2007
Once again, I learn a lot just reading posts to this list. I might add I
found out some more basic info on this topic at
On 4/18/07, Gavin McCullagh <gmccullagh at gmail.com> wrote:
> On Tue, 17 Apr 2007, Ian Moore wrote:
> > File access permissions. Basically we have about 5 machines which users
> > log onto with using a location specific user account.
> It's up to you but I try to avoid location-specific accounts like the
> plague. It keeps people in that tortured "file X is on computer Y only"
> mentality. If they are given their own accounts they can have their own
> files and settings whichever computer they sit down at. I'm sure you have
> your reasons of course, but if at all possible, I'd give people individual
> accounts. However, that doesn't solve this problem:
> > As people often work on the same documents and files but at different
> > times and from different workstations we saved most things to a shared
> > directory called 'public'.
> First an executive summary:
> - make sure all involved users are in some group
> - use chgrp to set the group of the shared directory
> - use chmod to set the setgid bit and give write access to the group on
> your shared directory.
> - set everyone's default umask to 0002 in /etc/profile
> Now an explanation:
> There's probably two things you need to look at. One is which group files
> are created with by default (setgid on directory) and the other is the
> permissions files are created with (umask). What I presume you want is a
> situation like this:
> gavinmc at boing:~$ ls -la /shared/
> total 8
> drwxrwsr-x 2 root admin 4096 2007-04-18 09:09 .
> drwxr-xr-x 21 root root 4096 2007-04-18 09:03 ..
> -rw-rw-r-- 1 gavinmc admin 0 2007-04-18 09:03 somefile
> So /shared is owned by "root", with the group "admin" and somefile has
> created by gavinmc allowing members of the group "admin" write
> access. The
> group "admin" has write access so all of those users can create files in
> /shared. Also, the setgid bit is set on /shared which means that new
> created in that folder will automatically have the admin group associated.
> This is done with
> sudo mkdir /shared
> sudo chgrp admin /shared
> sudo chmod g+w /shared
> sudo chmod g+s /shared
> Now, the next thing is, when a user "sarah" creates a file, the group must
> have write access to the file. As Denis says, umask is what you want
> Every user session has a "umask" which dictates what permissions are given
> to files they create. The norm is 022, meaning those in the file's group
> and others get read access but not write access. Below I create a file
> somefile3, then change my umask and create another. Note in the second
> case that the group "admin" gets write access.
> gavinmc at boing:~$ umask
> gavinmc at boing:~$ touch /shared/somefile3
> gavinmc at boing:~$ ls -la /shared/somefile3
> -rw-r--r-- 1 gavinmc admin 0 2007-04-18 09:17 /shared/somefile3
> gavinmc at boing:~$ umask 0002
> gavinmc at boing:~$ touch /shared/somefile4
> gavinmc at boing:~$ ls -la /shared/somefile4
> -rw-rw-r-- 1 gavinmc admin 0 2007-04-18 09:18 /shared/somefile4
> If you look at the last lines of /etc/profile, the umask for all users
> set there. Edit the file and change the umask command from 0022 to 0002.
> Then logout and log back in again. At a shell, type umask to make sure
> get 0002. Then create a file and you should see group write permissions
> the new files you create.
> As /etc/profile sets everyones umask, the same should now be true for
> everyone else.
> > The partial solution we found was to connect to this public directory
> > using a samba share, shortcut link located on the desktop. This was
> > already setup anyway for our Window machine on the network.
> This is due to the way samba maps unix to windows file permissions. There
> is a "create mask" setting in smb.conf which you can modify similarly to
> linux umask which sets the permissions created when files are created over
> a samba share.
> One final warning. You should explain to people that they must be careful
> two people do not edit files at the same time. Linux itself (unlike
> windows) doesn't usually enforce file locking. This can be good and bad,
> depending on the situation.
> edubuntu-users mailing list
> edubuntu-users at lists.ubuntu.com
> Modify settings or unsubscribe at:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the edubuntu-users