Red Hat Bugzilla – Bug 1257858
lock files in /etc
Last modified: 2015-09-10 11:20:01 EDT
We are using lusermod in order to modify user accounts on a readonly filesystem. This was possible till version 0.60 but more recent versions try to create a random lock file in /etc. As we do not mount the complete /etc read-writable this fails. Could the lockfiles please be created e.g. in /var/lock instead?
Thanks for your report.
I’m afraid moving the randomly-named lock filess would not be enough; libuser is also creating new versions of files, and using rename() (e.g. /etc/passwd+ renamed to /etc/passwd).
This atomic replacement using rename() is necessary to fix a security vulnerability (#1233052). rename() only works within a single filesystem, which can only be reasonably guaranteed only by working within /etc.
(And rename() also does not work if the source or destination are bind mounts.)
So, for security reasons it is necessary to give libuser write access to the directory (not necessarily to all files in there but write access to the directory allows replacing the files anyway). I’m afraid I can’t see any other option; if you do, please reopen this report.
Would it be possible to place those lock files in /var/lock instead? So we would get a defined set of files that we could make read-writable (e.g. /etc/passwd, /etc/passwd+, /etc/shadow, /etc/shadow+, /var/lock).
rename() _to_ /etc/passwd must work; which implies write access to the _directory_.
(Also, /var can be a separate partitition, and is thus unsuitable; really anything outside /etc or perhaps /, which is even worse, is not a possible path).
Ok, got it. Thanks for making that clear.