MultiUserManagement

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

User's perspective

See http://wiki.debian.org/UserPrivateGroups

Provide default collaboration directories for groups (and for users)

For each <groupname> create:

/home/share/<groupname>           (world readable, sgid writeable for members of the group)
/home/share/<groupname>/private   (readable (and writeable) only for members of the group)
/home/share/<groupname>/incoming (world writeable, sticky files, non-public (not browsable) filenames)

For each <user>:

/home/<user>                    (These already exist, and world readable by default as well)
/home/<user>/private            (A private place for the user, read/write only for user)
/home/<user>/incoming           (world writeable, sgid, sticky files, non-public (not browsable) filenames)


Whoever wants to make the homedirs (/home/<user>) non-traversable (non-x),
needs to introduce a separate place for shares:

/home/share/<user>              (world readable, rw for the user, and also its XDG_PUBLICSHARE_DIR)
/home/share/<user>/private      (symlink to /home/<user>?/private?)
/home/share/<user>/incoming     (world writeable, sgid, sticky files, non-public (not browsable) filenames)
(However this means user's homedirs would behave differently from groupdirs and the UPG usage scheme.)

  • (204577 deals with the last point)

Benefits

  • The user private group scheme implemented in debian/ubuntu will actually get set up correctly, working as intended.
  • Users are given an easily usable and understandable way to collaborate without the need of manually tweaking file permissions.
  • The same method can be used for finer-grained collaboration, by creating arbitrary (sub)groups of users.
  • When running apps under a different user ID (e.g. 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.

  • For more, also refer to the redhat manual.

Mini Howto

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

  • Make all users belong to the users group. Either by: echo "*; *; *; Al0000-2400; users" >> /etc/security/group.conf (Then all users are dynamically added to the "users" group every day 24x7 when they log in.) or by changing the default groups in /etc/adduser.conf and manually adding all existing user accounts to the "users" group. (253103)

  • manualy create a group directory for all users (grop "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

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

Further related Ubuntu bugs:

252351 provide informatin about users and file permissions

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

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. (-- nalimilan 2009-11-26 13:30:23)

    • If the homedirs are really to be made (rx) private, other users are not allowed to traverse into any public subfolders. (If they are, they could read files (those worldreadable by default) they know the names from (i.e. config files) even if directory listing is not allowed.) ("Permissions depend on the file and the path to it.")
    • If the homedirs are really to be made (rx) private the public (network) share, but also incoming/ directories etc. (now necessarily outside of $HOME) could be set appropriately in XDG_PUBLICSHARE_DIR etc., but the $HOMEDIR would then behave differently from regular directories (be an exception) and would not serve as good example for the "Permissions depend on the file and the path to it." scheme presented here.

  • (And /home/<user>/Private is already used by eCryptfs anyways.) (-- nalimilan 2009-11-26 13:30:23)

    • Sounds like its a sane default then. (Setting aside that it is upper case.) Private/ can be private in terms of permission and (additionaly) of encryption without conflicting. Is it used as a file or mountpoint?
      • Actually ~/.Private may be quite a misnomer for a ~/.cryptfs file. The cryptfs currently gets mounted as a private (rwx --- ---) homedirectory, but encryption and private permissions are rather different things.

  • I don't even know where to begin with my concerns about "permissive $HOME's".(-- ckrzen 2024-04-19 18:54:07)

CategoryDocumentation

MultiUserManagement (last edited 2019-05-24 17:34:40 by ckrzen)