Bug 187373 - python libuser interface could use support for alternate roots
Summary: python libuser interface could use support for alternate roots
Alias: None
Product: Fedora
Classification: Fedora
Component: libuser
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Miloslav Trmač
QA Contact:
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2006-03-30 16:35 UTC by Chris Lumens
Modified: 2007-11-30 22:11 UTC (History)
0 users

Clone Of:
Last Closed: 2006-04-03 19:29:44 UTC

Attachments (Terms of Use)

Description Chris Lumens 2006-03-30 16:35:35 UTC
It would be useful if the python interface to libuser allowed me to specify an
alternate environment it would operate in.  For instance, in anaconda we'd like
to be able to use libuser for managing the root password, but we need to be able
to modify the password files mounted under /mnt/sysimage instead of the ones in
the install media.

Something simple like the following would probably work:

        admin = libuser.admin(root="/mnt/sysimage")

Comment 1 Miloslav Trmač 2006-04-01 18:03:23 UTC
If all you want to do is to change a password, you can use an
anaconda-specific config file, something like this:

crypt_style = md5
modules = files shadow
create_modules = files shadow
directory = /mnt/sysimage/etc
directory = /mnt/sysimage/etc

Adding chroot support with exactly the same semantics would be rather ugly
because libuser also uses libc's NSS, so it would have to fork & chroot for the

Would using a config file as described above be good enough for anaconda?

(Below are some notes from my investigation, please ignore)
Using NSS:
handle_default_useradd_key(): (adding users)
lu_default_int(): "users" (creating users)
libuser_get_user_shells: *usershell
lu_mailspool_create_remove: "mail", fallback after libuser

Using NSS with fallback to libuser:
lu_get_first_unused_id(): (adding)
convert_{group,user}_name_to_id(): (enumerate)

read_file(): open, both for libuser.conf and imported config files
lu_{files,shadow}_uses_elevated_priviletes: access
set_default_context: getfilecon
lu_files_create_backup, lu_files_*enumerate*: open
generic_{lookup,add,mod,del,lock,is_locked,setpass}: open
lu_mailspool_create_remove: open, unlink;
lu_homedir_{populate,remove}: *

Comment 2 Chris Lumens 2006-04-03 19:18:14 UTC
Yes, I believe that would work just fine for us.

Comment 3 Miloslav Trmač 2006-04-03 19:29:44 UTC
OK, let's leave it as it is, at least for now.

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