Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
kdrobnyh opened this issue Aug 26, 2023 · 7 comments
Labels

Comments

@kdrobnyh
Copy link

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 rfjakob added the bug label Sep 17, 2023
@rfjakob
Copy link
Owner

rfjakob commented Sep 17, 2023

Ugh, -force_owner looks like a mess right now. I guess #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
Copy link
Contributor

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
Copy link
Author

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
Copy link

infinityb commented Sep 19, 2023

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
Copy link
Contributor

(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
Copy link

sam42contact commented Feb 5, 2024

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
Copy link
Owner

rfjakob commented Sep 1, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants