Can't create folder or file under a normal user when mounted by root with force_owner

[kdrobnyh]

I mount an encrypted folder under the root user, but try to access decrypted content via a separate user (1001:1001). I specify -allow_other flag as well as -force_owner 1001:1001. When I access the decrypted content using the specified user, the access seems to be limited: I can modify the existing files (e.g., created by root before), but can't create any new files or folders, even though the owner of the content is 1001:1001. Any ideas what is wrong? It looks like a bug to me.

Steps to reproduce:

• create a new user (1001:1001);
• # gocryptfs -init -xchacha -config ~/crypt.conf crypt
• # gocryptfs -openssl true -config ~/crypt.conf -allow_other -force_owner 1001:1001 crypt plain
• # cd plain
• # mkdir new
• # touch foo
• Login as the user mentioned before (1001:1001)
• $ mkdir new2 gives a permission denied error
• $ touch bar gives a permission denied error
• $ mv new new2 is fine
• $ mv foo bar is fine
• Editing bar is fine

[rfjakob]

Ugh, -force_owner looks like a mess right now. I guess https://github.com/rfjakob/gocryptfs/pull/340 made it inconsistent, because that only affected the code paths that create new files.

I'm not sure what behavoir we want, though.

@kdrobnyh what do you want to do with -force_owner / why do you use it?

@charles-dyfis-net same question for you. Would it be OK that -force_owner implies read-only? Or should the files be created as root-owned?

[charles-dyfis-net]

I no longer own the project that was making use of gocryptfs here. To my recollection this would be a no-go; but I've pinged my successor so he can jump in here.

[kdrobnyh]

Thanks for your reply! I have several programs running under different users inside rootless docker containers, so I give those programs access by mounting with -force_owner. I can't really mount each of the folders separately from under the corresponding users, because those users do not formally exist in the host system (they exist only as subuid/subgid).

[infinityb]

Hey - I'm @charles-dyfis-net's successor.

We use gocryptfs in a similar way to @kdrobnyh above, where a handful of programs (under different users) are given access to directories through gocryptfs which starts as root, but drops privileges and runs as a specific (non-root) user which accesses the underlying storage as that uid. The reason to have a specific storage-access user is to simplify deployment while maintaining isolation between users(/services) - this is on NFS where the NFS server is being managed by end users.

Hope this helps explain our usage, & thanks for taking us into account.

Note: updated description to be more clear. thanks Charles.

[charles-dyfis-net]

(To expand a little from my increasingly-outdated memory, the goal was not just simplifying deployment -- a lot of this in the original design was about sandboxing; subtree A, using gocryptfs key A, and exporting content from a specific subtree of the shared for use only by account A, was also used as a security control, ensuring that a compromise of service account A couldn't be used to read data associated with service accounts B, C or D, despite only requiring the customer/user to set up one account on their NFS server; because all these services are creating new data, mkdir is of course essential)

[sam42contact]

Hello, on my end, the crypted folder is owned by user1. I decrypted and mounted the folder using root and force_owner as user2. What I experience is the following (as user2):

• I can read existing files.
• I can rename existing files.
• I can edit existing files.
• I can delete existing files and folders
• I CANNOT create new files.

My version of gocryptfs is v2.4.0.

Edit: As a temporary solution, one could use bindfs to first mount the crypted folder as user2.

[rfjakob]

I guess the only sane thing to do here is to create the new files as 1001:1001 (or whatever -force_owner is set to).

Creating new files as root seems dangerous as it allows to create root suid binaries.