Bug 1255175 - useradd -R reads /etc/login.defs from outside of the chroot
Summary: useradd -R reads /etc/login.defs from outside of the chroot
Alias: None
Product: Fedora
Classification: Fedora
Component: shadow-utils
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Fedora Extras Quality Assurance
Whiteboard: RejectedBlocker
Depends On:
Blocks: 1255066
TreeView+ depends on / blocked
Reported: 2015-08-19 20:34 UTC by David Shea
Modified: 2015-09-01 03:36 UTC (History)
5 users (show)

Fixed In Version: 4.2.1-3.fc23
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-09-01 03:36:05 UTC
Type: Bug

Attachments (Terms of Use)

Description David Shea 2015-08-19 20:34:43 UTC
Description of problem:

If I have a chroot filesystem at, say, /mnt/sysimage, and I run:

useradd -R /mnt/sysimage newuser

useradd will read /etc/login.defs instead of /mnt/sysimage/etc/login.defs, and it will fail if /etc/login.defs does not exist.

groupadd, on the other hand, uses /mnt/sysimage/etc/login.defs.

Version-Release number of selected component (if applicable):

Comment 1 David Shea 2015-08-19 20:50:28 UTC
Assuming that reading the login.defs from the chroot is the intended behavior (it's the behavior I'd like, anyway), this patch is working for me:

diff -purN shadow-4.2.1.orig/src/useradd.c shadow-4.2.1/src/useradd.c
--- shadow-4.2.1.orig/src/useradd.c	2015-08-19 16:38:31.047854910 -0400
+++ shadow-4.2.1/src/useradd.c	2015-08-19 16:39:05.208461058 -0400
@@ -1937,6 +1937,8 @@ int main (int argc, char **argv)
 #endif				/* USE_PAM */
 #endif				/* ACCT_TOOLS_SETUID */
+	process_root_flag ("-R", argc, argv);
 	/* Needed for userns check */
 	uid_t uid_min = (uid_t) getdef_ulong ("UID_MIN", 1000UL);
 	uid_t uid_max = (uid_t) getdef_ulong ("UID_MAX", 60000UL);
@@ -1950,8 +1952,6 @@ int main (int argc, char **argv)
 	(void) bindtextdomain (PACKAGE, LOCALEDIR);
 	(void) textdomain (PACKAGE);
-	process_root_flag ("-R", argc, argv);
 	OPENLOG ("useradd");
 #ifdef WITH_AUDIT
 	audit_help_open ();

Comment 2 Fedora Blocker Bugs Application 2015-08-26 19:38:48 UTC
Proposed as a Blocker for 23-final by Fedora user sbueno using the blocker tracking app because:

 This bug prevents sshd from starting in the installer, which makes it impossible to perform an interactive installation on s390x. I know that s390x is not a primary arch, hence the 23-final milestone.

Comment 3 Tomas Mraz 2015-08-27 13:45:25 UTC
The patch is not quite correct but the behaviour is buggy. I'll fix it.

Comment 4 Fedora Update System 2015-08-27 15:10:57 UTC
shadow-utils-4.2.1-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-14416

Comment 5 Adam Williamson 2015-08-31 17:17:56 UTC
Discussed at 2015-08-31 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-08-31/f23-blocker-review.2015-08-31-16.01.log.txt . As this is just the cause of #1255066, the same resolution applies: For primary arches this is an inconvenience not a showstopper, and secondary arch issues cannot be release blocking by policy, so this is rejected as a release blocker. Note that doesn't mean it won't be fixed, just that we won't delay primary arch releases to fix it.

Comment 6 Fedora Update System 2015-08-31 18:52:49 UTC
shadow-utils-4.2.1-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update shadow-utils'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14416

Comment 7 Fedora Update System 2015-09-01 03:36:04 UTC
shadow-utils-4.2.1-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.