owner can't access when not in primary group - how to change this?

[jonleivent]

I have a gocryptfs setup for a user with pam_mount to mount their home dir, and it is working very well. I have a use case that requires that I change the user away from its primary group : for instance by using sg. As soon as I do that, the user loses the ability to access their decrypted home. Is this expected? Note that the user (uid) stays the same, it's just that when they are no longer in their primary group, they can't access their encrypted home.

I can probably fix this by adding allow_other, but I don't want to lose the added security of not using allow_other. Is there a workaround?

[lechner]

Hi @jonleivent,

I haven't tried your setup, but that strikes me as a FUSE (or perhaps a go-fuse) question.

Also, I don't use groups much, but I thought one could be a member of many. I am not sure I understood what you meant by changing the user "away" from their primary group.

Kind regards
Felix

[jonleivent]

I think I will ask the question at https://github.com/hanwen/go-fuse as well, but that project doesn't have a Discussions page, so I will have to file it as an issue. I don't know where in the stack the check of the user/group is occurring - it might even be below go-fuse.

To clarify what I meant by "change the user away from its primary group". I meant that a process is created that has the user's UID but not the user's primary group's GID. That process cannot access the user's home, even though the process has the user's UID.

[lechner]

@jonleivent Thanks for clarifying! I applaud your effort and have likewise been reluctant to use allow_other.

For example, I cannot use sudo for executables resolved via symbolic links in Guix profiles when the latter are located in my encrypted home folder.

[rfjakob]

I did not know sg exists. Thanks for that information :)

As for the problem, looking at https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/fs/fuse/dir.c?h=v6.3.2#n1308 , this seems to be enforced by the kernel. All of GID, EGID, SGID have to match for the access to be allowed.

I think allow_other is the only way.

[jonleivent]

Bummer.

[jonleivent]

@rfjakob
I know this is going to sound off-subject, but what happens if the append-only extended attribute (chattr +a) is set on the top-level directory in a gocryptfs source tree?

The reason it's not changing the subject is that if I'm going to use allow_other, then I need some other way to make sure that no other users can get into the decrypted tree. One way to do that is to chmod the top dir to not allow anything but owner (chmod 700), but that doesn't rule out the owner's own accidental (or a malicious process it owns) chmod'ing it back to something like 755. But, if I chattr +a or +i the top dir as well as chmod 700, that does prevent the owner from chmod'ing it back (because chattr +-i and +-a require capabilities that normal users don't have). Chattr +a is less constraining than +i, since the owner can still create files and directories, just can't delete or move them - so I'll use that. For home directories, append-only isn't such a bad way to go, as most file activity takes place in subdirs anyway after a while. I think I can manage with it.

But, gocryptfs itself stores meta-info files in the root directory. So my concern is whether gocryptfs will try to do something to those files that will fail due to the append-only rule. Any idea if that will happen? Any moves or deletes? It can still write to those files, even truncate them. The modification dates on those files suggests this should be safe, but my luck tends to run the other way.

I just tested it and it seems to work so far....

[jonleivent]

@rfjakob
Nevermind - I think I have an alternate solution that doesn't need append-only dirs or allow_other.
Thanks for your help.