MultiUserManagement

Revision 23 as of 2009-11-26 15:18:13

Clear message

Related Blueprint: https://blueprints.launchpad.net/ubuntu/+spec/local-file-share

See also http://wiki.debian.org/MultiUserManagement

User's perspective

(This should be true, but still needs the fixes from below.)

It is easy for multiple users to collaborate on debian/ubuntu systems.

Just keep in mind that access permission to a file always depends on the permissions of the file itself AND the permissions of the directory path to it. By default files are readable for whoever has access to them, just as paper files are, but not writeable. If you don't want others to read your files, keep them in a private/ subdirectory. The path into your home directory is not restricted, just as the path others can take to ring your bell at home is not restricted. As a matter of fact you may post some files on your door, for others or to read. For example many programs read config files that you deposit in your home path. Besides, other users can drop files (for you personally) in your ~/incomming/ directory.

All this can work because the primary group of each user is set to a private user group (UPG) by default. (A group without any mentioned members in /etc/group, named equal to the user.) This allows to grant write permissions to created files for the group by default. No one exept the owning user will be able to write to the file. Exept that is, if it has been created in a group directory...

Group directories (directories with the set-group-id flag set) are special places (that again all users are able to visit) where the members of the group that owns the directory can write files in it. According to the set-group-id flag files created in the group directory will belong to the creating user who wrote the file and to the group *the directory belongs to*. The result is that all members of the group can work on the files in a groupdir of theirs. Other than that, group directories work just like home directories. So if a file for example should be readable only by group members, again put it into a private subdirectory.

Group directories may be set up by regular users in their home directories, or by the the system administrator or (automatically) by the addgroup command under /home/group.

Collaboration Directories

/home/group/users               (writeable for all users of the system)
/home/group/<groupname>         (writeable for members of the subgroup)
/home/group/<groupname>/private (rw only for users of the group)
/home/<user>/incomming          (writeable for p2p collaboration, non-public filenames)

As a private place for users either just a subdirectory can be provided 

/home/<user>/private            (readable (and writeable) only for the user)

or the homedirs (/home/<user>) could be made private by default and separate shares can be introduced under

/home/share/<user>              (rw for the user and its XDG_PUBLICSHARE_DIR 
  • (204577 deals with the last point)

Benefits

  • The user private group scheme implemented in debian/ubuntu can actually work.
  • Users are given an easily usable and understandable way to collaborate without the need to manually tweaking file permissions.
  • The same method can be used for finer-grained collaboration, just by creating (sub)groups of users.
  • When running apps under a different user ID (i.e. firefox) upload/download files etc. can be accessed using the same way out of the box. Without the need to add the primary user to the firefox private user group.
  • Refer also to the http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/s1-users-groups-private-groups.html redhat manual

Mini Howto

Currently however you need to fix the following things (as root) to enable collaboration between users on a ubuntu system:

  • /etc/pam.d/common-session: add line "session optional pam_umask.so usergroups" (253096)

  • /etc/profile: remove the line that sets the umask (379341)

  • Make all users belong to the users group: Either by adding the line "*; *; *; Al0000-2400; users" to /etc/security/group.conf or by changing the defaults in /etc/adduser.conf and adding all existing users to the users group. (253103)

  • manualy create a group directory for all users: (379431)

    • mkdir /home/group/users
    • chmod o+t /home/group/users
    • chmod g+s /home/group/users
    • chown root:users /home/group/users
  • manualy create group directories for each <group>: (379421)

    • mkdir /home/group/<group>

    • chmod o+t /home/group/<group>

    • chmod g+s /home/group/<group>

    • mkdir /home/group/<group>/incoming

    • chmod o+t /home/group/<group>/incoming

    • chmod a+w /home/group/<group>/incoming

    • mkdir /home/group/<group>/private

    • chmod o-rx /home/group/<group>/private

  • also provide all users with ~/incoming and ~/private directories. (379451)


Further related Ubuntu bugs:

252351 provide informatin about users and file permissions

487729 /etc/login.defs propagates incorrect information

246192 / 275304 gksu to regular users broken/wrong ownership of .Xauthority and /tmp/libgksu-xxx

Comments/Discussion

  • About /home/<user>/private dirs: I'd rather have the home dirs be private by default, and use the already existing /home/<user>/Public directory to share files, since while it's already used to share files over the network: it makes sense to merge both features, making it easier to understand for most users. People can still fine-tune permissions if they want some folder to be readable, and e.g. symlink them to their public folder. (And /home/<user>/Private is already used by eCryptfs anyways.) (-- nalimilan 2009-11-26 13:30:23)


CategoryDocumentation