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")
If all you want to do is to change a password, you can use an anaconda-specific config file, something like this: [defaults] crypt_style = md5 modules = files shadow create_modules = files shadow [files] directory = /mnt/sysimage/etc [shadow] 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 lookups. 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) Other: 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}: *
Yes, I believe that would work just fine for us.
OK, let's leave it as it is, at least for now.