Allow to share files between users on the same machine
At the time, there's absolutely no easy way for a user to give a file to another user on the same computer: you'd better use an email. It would be nice to add a "Shared folder" common to all physical users of the system, that would be used in home desktops: you should be able to copy a file to there and another to read/edit it. In an improved version (to overdo Windows here), we could create folders to share files exclusively with one user. On desktops, with typically < 5 users, this is not an issue: in Places -> Computer, there is perfectly fit space for it.
On the technical side, it appears that default permissions management is not able to do that out of the box. ACLs allow an option (setfacl -d) to keep the permissions of the parent folders for the files created within; though, copying a file won't work (AFAIK and without tricks). A solution would be to use a script to change the permissions every time a file is updated (using dbus and inotify?).
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Discussion
- Series goal:
- None
- Implementation:
-
Not started
- Milestone target:
- None
- Started by
- Completed by
Whiteboard
Note that the blueprints' saying that "there's absolutely no easy way for a user to give a file to another user on the same computer" is only true with the current ubuntu configuration, but is not true, and has never been true for unix/linux systems in general for decades. Unix directories can get set up with a proper scheme, during install, and user/group addition/deletion.
For a short overview refer to https:/
The UPG scheme provides a well working method without requiring ACLs at all, for users to collaborate. Unix/linux allows to define many groups, with different sets of users, and access to files is determined by the file location, i.e. in what group directory a file is put. Yes, standard file permission only allows "u-g-o", but this is enough to define an arbitrary number of group directories and users belonging to multiple different groups to use them without any hassle. Please read up on the UPG scheme.
----
ceg: The following apperently was an addition from someone who has not known and understood the user privat groups (UPG) scheme at all, and is not familliar with how multi-user linux systems can be set up properly. (non-existing arbitrary limits, wrong examples, etc.):
----
Bib: how to have the whole tree TREE writable by group1, read/browse only by group2, and no access by others?
ceg: While using only standard file permissions does not allow for ACL features, the standard permission system allows quite bit if you know how to use them. (Same with ACLs or mostly anything.)
Your example sounds common for webservers and may be solved with "lock" directories as parent to the group directory, or bind mounting files into different group dirs.
https:/
Even if not and the long-standing solutions are not that known/obvious to ubuntu, ubuntu has no reason to wait for ACLs getting fixed, but can configure proper UPG and group dir handling.
----
Bib: The above comment lets think that default permissions management allows having 2 different groups for a __single__ file|dir in the aim to get this example: g=srwx,g2=rx,o=---.
AFAIK only u-g-o is possible, not u-g-g2-gn-o. As stated in the 2nd paragraph of this very blueprint, only ACL could do this if they worked as intended, i.e. if e.g cp would respect any default acl __when it meets one__. This is very clear.
A workaround would be something with inotify|dbus as already stated... another (ugly) one would be a cron job searching for new files|dir in the tree since last run, and applying the default acl of the parent of each.
----
Bib: So now, let's admit 4 users is the de facto, non arbitrary, upper limit for a desktop... I know a friend of mine having 4 children and not reach enough to buy a second computer. Even if he could, all 6 family members couldn't have their own login account in each computer (this would break the magical 4 limit).
The "refer ...MultiUserMan
/srv/FamilyData:
group1 mum-dad => rwx
group2 kids => r-x
others => --- (think to guest)
/srv/FamilyData
group1 mum-dad => rwx
group2 kids => rwx
others => ---
/srv/FamilyData
group1 mum-dad => rwx
group2 kids => ---
others => ---
Because of cp/mv breaking acl automatic inheritance, acl are of no help here, just broken, making the whole OS as fun as a fridge or a washing machine. Don't even talk about the files managers.
When done, remember 20 years ago: Windows NT4 introduced ntfs with fullfeatured ACL targetted to enterprises. Less than 10 years later they merged the old dos/9x branch, giving up the FAT permissions (single read-only was not a big loss) for the default system FS, giving the ntfs robustness, versatility, granularity into the general public computers. Since XP (even home release), the ACL are around, even if you still beleive the "shares" we had in WFW3.11, then 9x up to w10 are still the same. ACL are underlying: if you don't see them at first glance in "home" products, it is just a commercial restriction. NT4~W10 shares won't work without the acl background.
In the lap time, GNU/Linux prevaricated about ACL, arguing the 1003.1e draft17 is withdrawn.
This blueprint is just in the same state it was 6 years ago when Milan posted it.
---
Helpful and related links:
* https:/
* http://
* https:/
* https:/
* https:/
