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 2026-09-21 08:49:29)
- Placing convenience-over-privacy in this post-GDPR / Facebook & Twitter leaks / Equifax breach / etc. seems to be unconscionable.
- By default, the two dominate Desktop OS's(Windows & macOS) either totally block or at least selectively block(Desktop, Documents, Pictures, etc.) access to $USER $HOME dirs by other $USER's unless intentionally allowed by an $ADMIN or $USER.
- Cloud storage, NAS's or server-based networks make the sharing of files simple and convenient and are what the majority of $USER's understand or expect.
- I posit that there are far more Windows-trained $ADMIN's, CIO's, CTO's, etc. coming to Linux for the first time now("WSL 2", "Windows 7" nearing EOL, etc.) than in the entire history of the project. I make no bones about saying that they _will_ notice this issue and ascribe a "privacy-hole" label to it. Worst case: recommend scrapping any migrations from Windows or macOS due to indications that privacy is not a serious concern to Linux developers and Ubuntu in particular.
- Experienced Linux or *nix $USER's will already know how to twiddle the needed bits to make dir's open and available to other local accounts. If they are the target market for "Desktop Linux", then--we'll remain a third-runner, geeks-only, toy/hobby Desktop OS until we get over ourselves and make $USER privacy(security) a priority over lazy-access.
- My comments are assuming that the $USER has selected to install the $HOME dirs on a LUKS+LVM partition and, optionally, to passwd protect the BIOS boot options. These concerns are targeting the inside of those security perimeters, where a new $USER may be and likely presumming privacy-by-default. The effort to open a file manager app or terminal and then 'cd' to or 'cp' from another $USER dir is far easier than circumventing simple "physical" access constraints which are not the responsibility of the OS anyway. My concerns are all about "reasonable expectations of privacy" and the potential for insider snooping.
- If I invite you into my house(physical), then I don't expect you to go through my filing cabinets or closets, when I'm not looking, without giving you those "permissions(0755)". "Good fences make good neighbours" and "Locks keep out only the honest". How can I make this point any more clear?
- Recommended reading:

CategoryDocumentation