Bug 979815 - pyanaconda users.createLuserConf doesn't refer to login.defs, gets wrong LU_UIDNUMBER
pyanaconda users.createLuserConf doesn't refer to login.defs, gets wrong LU_U...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
19
Unspecified Unspecified
low Severity low
: ---
: ---
Assigned To: David Shea
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-30 16:26 EDT by David Woodhouse
Modified: 2014-04-07 11:05 EDT (History)
8 users (show)

See Also:
Fixed In Version: anaconda-21.28-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-04-07 11:05:55 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
dwmw2: needinfo-


Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2013-06-30 16:26:10 EDT
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 17:57:08 EDT
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 19:24:47 EDT
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 09:47:44 EDT
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.

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