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
RO RFS and passwd change, bind mounting shadow/passwd does not work #821
Comments
would be nice to configure the tools to use a more standard |
We don't want to just change the lock location for two reasons. One is that, once we do, there might be two versions of passwd on the system using different lockfiles. The other is that /run is a different filesystem, and it might be pretty easy to have a situation where two admins have their own private tmpfs at /run. Heck, that - polyinstantiated directories at /tmp and /run for logins with different security (selinux MLS) levels - was the whole justification for unshare(2). What we can do is try to open the /etc/shadow.$pid (and then link it to /etc/shadow.lock) as we do now, but if we get a -EROFS back, then we can fall back to using /run. |
That would work, thanks, would shadow.lock also follow this move? |
I just tested the new --prefix option but quickly found that normal users cannot use it as --prefix drops privs, As is now, I cannot think of a way for normal users to change passwd, --root nor --prefix works |
Now I have tried moving locks to /run, --prefix, --root and symlinks and neither works for RO RFS. However, using the various XXX_FILE #defines I could move pw files from /etc to /etc/pwdb an then bind mount /etc/pwdb to RW FS. Hence the PR in #834 to moved subuid/subgid to defines too. |
To make passwd change work on a RO Root FS one can bind mount /etc/{passwd,shadow,shadow-} into a RW FS.
This does not work any more as now passwd creates a tmp(lock?) file with PID num in file name which
cannot be bind mounted.
Does that that file need to be in /etc or can it move to say /tmp ? or have a fixed name ?
Using --root can be used instead but then the user needs to pass --root /some/new/root
Can the default for --root be configured somewhere so users does not need to pass --root ?
The text was updated successfully, but these errors were encountered: