This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 187373 - python libuser interface could use support for alternate roots
python libuser interface could use support for alternate roots
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: libuser (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-30 11:35 EST by Chris Lumens
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-03 15:29:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Chris Lumens 2006-03-30 11:35:35 EST
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 13:03:23 EST
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}: *
Comment 2 Chris Lumens 2006-04-03 15:18:14 EDT
Yes, I believe that would work just fine for us.
Comment 3 Miloslav Trmač 2006-04-03 15:29:44 EDT
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.