Bug 979815

Summary:	pyanaconda users.createLuserConf doesn't refer to login.defs, gets wrong LU_UIDNUMBER
Product:	[Fedora] Fedora	Reporter:	David Woodhouse <dwmw2>
Component:	anaconda	Assignee:	David Shea <dshea>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	19	CC:	anaconda-maint-list, dshea, dwmw2, g.kaviyarasu, jonathan, mkolman, sbueno, vanmeeuwen+fedora
Target Milestone:	---	Flags:	dwmw2: needinfo-
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	anaconda-21.28-1	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-04-07 15:05:55 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description David Woodhouse 2013-06-30 20:26:10 UTC

Since https://fedoraproject.org/wiki/Features/1000SystemAccounts the libuser config is supposed to contain a section such as

[import]
login_defs = /etc/login.defs

This causes it to get the appropriate minimum uid from login.defs. 

However, when I use users.createLuserConf() from my firstboot module, it doesn't seem to do so and the user I get has UID 500 instead of 1000.

I can 'fix' this by manually adding the missing [import] section to the created file.

Comment 1 David Shea 2013-08-01 21:57:08 UTC

David, why are you calling an anaconda function from firstboot? createLuserConf is more there for rescue mode than anything; anaconda's regular user creation happens in a chroot, where it uses the libuser.conf from the installed system.

Comment 2 David Woodhouse 2013-08-01 23:24:47 UTC

I have a firstboot module which takes a user's Active Directory credentials (domain, user, password) and joins the system to the Windows domain with Samba. It adds a local user, who is authenticated with pam_winbind.

In fact I have stopped using pyanaconda.users now, and I'm just doing it directly with libuser. Using pyanaconda.users *also* ended up pulling in the new gobject stuff, which means it can't be used from firstboot as that uses the old pygtk.

I had already converted my UI code to pygobject, but ended up porting it *back* again when I gave up on the idea of porting to become an inital-setup module (since the promised documentation for that doesn't yet exist).

I don't know why it was calling createLuserConf() — that was probably just cargo-culted in from old anaconda or firstboot code. It probably should have been able to use the existing system libuser.conf. That's what my code does now, certainly.

If this *is* actually used from rescue mode, it'll still have the same issue though, surely? Although I suppose it only matters if you *create* a user, and we don't do that from rescue mode?

Comment 3 David Shea 2013-08-02 13:47:44 UTC

Fair enough. It turns out I was wrong about it being used in rescue mode, anyway: there's a static libuser.conf included in the install media, and the prompt before the rescue shell tells you to chroot into /mnt/sysimage before doing anything anyway. That libuser.conf should reference /mnt/sysimage/etc/logins.def, but I'm not sure that anything is actually able to use that libuser.conf for anything useful. I'll leave the bug open, since createLuserConf is used by the user and sshpw kickstart commands, but this doesn't appear to have a big impact and might end up just being a cleanup of some unnecessary code.