0

I.e. what I want is the Linux equivalent of Windows Public/Pictures.

The problem is that Linux file manager Nautilus doesn't apply default ACLs when you move a file into a folder/directory (nor good old set-group-id). Not even in the expected case, where the file is only in one directory at a time, i.e. it hasn't also been hard-linked into another directory.

So dragging photos from a plugged in camera can't work, even with a default ACL. Other users will be able to read the photos, but they won't be able to write to them. They're shown with a padlock in the file manager.

Amusingly it isn't using rename() in this case, because the move crosses filesystems. Nautilus is just providing consistent semantics in this case by re-applying permissions form the source file :trollface:.

Unfortunately I remembered this too late, after getting fed up instructing fellow users on how to use Digikam. (Digikam worked, because deleting photos from the card is a separate operation. So the photos are necessarily copied, instead of moved). I instructed them to write notes on using the file manager instead. Sigh.

So I know this isn't the expected usage, i.e. multi-user computers have not really been catered for. But is there any sensible way I could set this up for my fellow users?

I'm discounting any method that's harder for people to remember (over about a month) than the file manager one. That excludes Digikam; it has too many pointless choices, and then demands confirmation before removing images from the card, as if this whole operation was fraught with danger. (Also unfortunately, with our software we get an "import photos using Digikam" popup that doesn't work).

I'm also excluding any photo manager that can't save album's names (including a date) to the filesystem. If you can't export to Digikam, then you're not trustworthy enough to make me import from Digikam!

Environment:

  • Linux
  • Debian
  • Standard GNOME desktop
Improve this question
2
  • 1
    Hmm, maybe I'm wrong about Nautilus not letting the default ACL take effect. I think I can see the ACL being applied in getfacl, but there is also a "mask" which effectively disables it. I think this could effectively be caused by umask, in which case it there is no obvious way to fix it :(.
    – sourcejedi
    Mar 14, 2018 at 16:10
  • And fixing the umask is only half the problem :(. The image files are created by copying them from a camera (FAT filesystem). So I also want udisks fixed so I can change the mode on the mounted filesystem.
    – sourcejedi
    Mar 15, 2018 at 10:01

3 Answers 3

Reset to default
1

I forgot something else. If I can't write to a file, I can still remove it and replace it. And that's exactly the correct way to save a file. (Because you have to fsync() before you have a durable file, which you can safely replace the old one with).

It seems to work fine, you just have to ignore the padlocks :). E.g. I can rotate photos copied in by other users.

DISCLAIMER: Digikam appears to update photo metadata incorrectly. So that will silently fail (:trollface2:), leaving the (metadata) database inconsistent. Fortunately I don't care about doing tagging at the moment, but that's another one of those little traps for me to stumble into later.

Improve this answer
0

Amusingly it isn't using rename() in this case, because the move crosses filesystems. Nautilus is just providing consistent semantics in this case by re-applying permissions form the source file :trollface:.

I wish that was the only problem. But I get the same effective permissions when copying as well. It's true that the default ACL is applied, if I check with getfacl. However it also shows a "mask", and that the default-applied ACL is effectively disabled by the mask.

To even get copying to work... you don't necessarily need a default ACL; historically you would rely on the User Private Groups pattern, with the shared directory being marked set-GID.

Unfortunately modern GNOME is not developed for multi-user systems, and there are two issues which have broken it.

  1. udisks uses the ancient unix mask 0022 when mounting FAT filesystems, like a camera's SD card, on behalf of users.
  2. systemd bug (or "RFE" lol): Permit selecting "systemd --user" umask.

For example when you use cp to copy an image from the SD card, cp copies the original mode, capped by the current umask. So it is affected by both issues. (It can be affected by the first issue because you ran cp from inside the systemd --user service known as gnome-terminal-server.service).

(Another aspect of this situation is that Debian implemented UPG from early on, but then broke the umask when they implemented PAM. While this issue is much more straightforward to work around using PAM configuration, it perhaps illustrates a lack of demand, and perhaps it has contributed to the lack of awareness about UPG).

Issue 2 breaks the traditional use of UPG, which relies on a umask of 0002 and a set-GID shared directory.

However, when you use a default ACL on the shared directory, the umask is effectively over-ridden, and issue 1 is the "only" problem.

Improve this answer
0

I saw another approach suggested in Docker bug comments. There's a FUSE filesystem which alters permissions. There's a performance impact just from using FUSE, but FUSE isn't as bad as you might think. Check out http://bindfs.org/

Example line for /etc/fstab, which allows users who have been added to the photos group:

/home/photos /home/photos fuse.bindfs nofail,allow_other,force-group=photos,perms=g+wX

It may also be possible to address with a few lines of code. Unfortunately it's not a completely trivial exercise. The second link below would work if you don't mind it breaking on newlines (or backslashes, apparently?) in filenames.

https://superuser.com/questions/139513/acl-and-moving-files-in-nautilus

http://positon.org/a-solution-to-the-umask-problem-inotify-to-force-permissions

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .