On Wed, 09.07.14 10:30, Miloslav Trmač (mitr@xxxxxxxxxx) wrote: > ----- Original Message ----- > > Hi, for Atomic I'd like to investigate the new systemd-sysusers, so I > > wrote up a Change: > > > > https://fedoraproject.org/wiki/Changes/SystemdSysusers > > A move to something more declarative makes sense (whether in systemd or through some kind of long-expected declarative rpm facility doesn’t matter to me much.) > > The sysusers tool _really_ needs to use an existing API to manage the > user database, though. Yeah, because we dodn't want to intrdocue any new API we have carefully made sure that whenever we write pasword, group and shadow files we use existing APIs from glibc, more specifically putpwent(), putgrent(), putspent() and crypt_r(). This is about creating system users, not normal users, hence using anything more fancy than glibc's native APIs is wrong. This is not stuff which is supposed to land on an ActiveDirectory server or so. It's stuff we need to be able to recreate during earliest boot, before the first daemons start, where little else but the most basic file system is around. libuser is not useful for this kind of environment. It appears to me that libuser unsuccessfully duplicates APIs from glibc, shadow-utils and other packages. I mean, it's quite weird to have both "passwd" and "lpasswd" around, and then complaining to me that we don't need multiple implementations. I mean, I really don't understand why there are two implementations of this in the first place! Anyway, I can understand the reason for libuser's existence, but for the low-level stuff we do with systemd here this is simply not the right tool for the job. We want something so low level that glibc is the only right option. Also, note that with systemd we try to find solutions that work for most Linux distributions. libuser appears to be quite common on Fedora, but I am pretty sure that systemd is not the vehicle to make it standard on other distributions too, in particular via such a relatively auxiliary feature of systemd. > As it is, the implementation > * validates names incorrectly How so? Can you elaborate? Point me to normative documents? > * breaks the configurable [UG]ID_MIN logic > (http://fedoraproject.org/wiki/Features/1000SystemAccounts, and yes, > that is actually used and needed) Well, this is something I really don't like. THis limit should be compile-time configurable, but not runtime-configurable. This is something the distributor needs to decide on, not something administrators should be able to change without recompiling. With systemd we kinda need to get something that works for the big picture, and I have doubts that this is something I want to see in the big picture, sorry. > * is likely to break various readers software by not updating the > shadow files Well, we don't update the shadow file, since a missing shadow entry is actually interpreted the exact way we want it here: as a disabled account, with no password set, where it is not possible to login to. That's the absolute correct default for system users. That said, it was brought to my attention that "pwck" doesn't agree with that. So I figure we'll update the shadow file too, the patch should be easy. It's on the todo list. > * doesn’t do any auditing. Well, looking forward to a patch to add this. > We are currently already in a bad position by having two major > implementations of maintaining the critical databases, we absolutely > don’t want any more. Good! We just use glibc APIs for writing those files. If you want only one implementation, why not get rid of libuser, and stick to glibc? ;-) > At this point this means systemd-sysuers should either run the > executables from shadow-utils, or link to libuser. (Or, I suppose, > use accountsservice, but that ends up calling shadow-utils.). Sorry, I am not going to play your stacking game. This is supposed to be simple, work in a minimal early-boot environment, and use stuff that is commonly around on Linuxes, from embedded to servers. glibc APIs are. libuser is not. > The plan is to have a single implementation, living around sssd. > (Jakub knows more.) Either of two API points above are planned to > use the sssd implementation, so can be relied on long-term. Mirek I am sorry, but to make this very clear: sssd has not place in early boot or in smaller setups. The problems we we want to solve with systemd we try to solve generically, and this means that I am not telling people to pull in sssd into the smallest of devices. sssd/libuser is fine for creating nomral users with, and fine for late-boot stuff, and fine for bigger setups. But other than that, glibc wins the day. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
