9

I've got a directory that I want to be owned by multiple users on the system. That is, I want any application running as oli to think those files are owned by oli, just as any application run by jim will think the same. This is not the same as just giving permissions as I have an issue where ownership matters. I trust all users in this scenario.

My immediate thought is some sort of bind mount that translates IDs transparently, and I'm sure there's a way to do this with fuse but quick and fast (kernel level) would be preferable for me.

To be clear, I'm not looking for actual mutiple ownership, I just want multiple users to see the files as theirs. There are a few different layers I know of in Linux that can map user IDs from one to another, so one of those is probably going to do the job here.

Oli
  • 299,936
  • 3
    Yeah I'd love groups to work. That was my first port of call. While everything does have write permission, one app in particular is checking for actual ownership. Annoying as heck. – Oli Feb 18 '24 at 14:02
  • 2
    As far as I know, a file only has one owner. Is that in a bug in the application?? What application is it? Do you have access to the source? – moo Feb 18 '24 at 20:29
  • 1
    https://superuser.com/questions/275493/how-can-two-users-be-the-owners-of-a-file#275496 – moo Feb 18 '24 at 20:30
  • 1
    @moo: I'm wondering if this is some kind of config file that's intended to be private, especially to something security-sensitive like ssh, so the program is checking ownership to defend against potential attacks due to misconfiguration. If it's not something like that, but just a program that for no good reason thinks it's smarter than the POSIX access() system-call or error returns from actual open attempts, then I'd call that a bug. – Peter Cordes Feb 18 '24 at 21:31
  • 1
    I'd say that might be worth filing a bug against the program for. Can you tell us which program does that? – marcelm Feb 18 '24 at 21:46

3 Answers3

13

Figured out the mount options for a completely in-Kernel ID mapping. This allows you to re-mount any directory somewhere else, with a different owner/group.

sudo mount --bind -o "X-mount.idmap=u:1000:1002:1 g:1000:1002:1" /home/oli/dir /home/other/dir

Both oli and other users can write to the same set of files thinking that they're the owner. This can also be persisted fairly easily to fstab.

Another option is bindfs/FUSE:

sudo bindfs --map=oli/other:@oli/@other /home/oli/dir /home/other/dir

That offers pretty transparent ownership. The other account sees the files as their own. I'd expect this to be slower than an in-kernel mapping.

Oli
  • 299,936
  • 1
    From the numerous inputs from others on this thread I gather that this appears to be a workaround that may have security implications. I would suggest to invite the kernel security team to assess whether, based on this thread, they find themselves inspired to implement any amendments. I recognize that this is a kernel feature currently, so probably everything is sufficiently covered, but a quick heads-up for review would perhaps not be a waste of anyone's time, after all. – Levente Feb 20 '24 at 16:17
7

Linux does not support multiple users owning filesystem objects. They must have one single owner.

This sounds like an XY problem. You think the solution is to have multiple owners, but you have not sufficiently explained the problem (you think the application cares about file ownership; why?) which could have other solutions, such as group ownership, running in a container, changing the user the application runs as, etc.

user10489
  • 5,583
  • 5
    I strongly second this. There are a handful of applications that do care about file ownership, but they pretty much always do this for legitimate security reasons (for example, ssh caring about ownership of ~/.ssh and the files within it, because other users controlling those is a huge security risk), so it’s extremely unlikely that this is really a good idea. – Austin Hemmelgarn Feb 19 '24 at 02:29
2

Here is a solution that does not require sudo/root and works for all mounts, present or future:

# Run each line in terminal
# (this needs to be changed if you want to make this into a script)
sed -n "/^$USER:/s/$UID/65534/gp" /etc/passwd > ~/passwd
sed -n "/^$USER:/s/$UID/65534/gp" /etc/group > ~/group


unshare -mr
mount --bind ~/passwd /etc/passwd
mount --bind ~/group /etc/group


unshare -U
your_app_here

This works by mapping the nobody and nogroup IDs to the current name. The last unshare does not set up any mappings so we become nobody and nogroup, which we rename (as well as preserve home directory and shell) with the above. I am assuming your apps are checking for the username of the files, and it is unknown whether this will break upon encountering apps that check against uid=65534. If you would let ls be your_app_here, you will see that every single file on the system looks like it's owned by you now even if you mount something later.

Daniel T
  • 5,362