On Wed, 09.07.14 13:47, Miloslav Trmač (mitr@xxxxxxxxxx) wrote: > > 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. > > I have already given examples where using a higher-level API would > avoid mistakes _and_ make future changes easier; and none of the > reasons offered convince me: Well, there appears to be no higher-level API around. You are saying yourself that libuser is going away. It's also not OOM safe, pulls in the glib dependency, it bypassed the low-level glibc APIs. So I am not sure what you are telling me with that... We use the only widely established API there is, and that has a future, that is documented (though not parcitularly well), that is OOM safe, doesn't pull in any deps, and is pretty much exactly as low-level as we need it. That's glibc. I really don't see any other option here. > > It appears to me that libuser unsuccessfully duplicates APIs from glibc, > > shadow-utils and other packages. > > Yes, it only duplicates a glibc API if we ignore all the code that > isn’t in glibc, including all the things that systemd-sysusers got > wrong; and shadow-utils doesn’t have a C API so libuser doesn’t > duplicate a shadow-utils API. Well, You should be aware that sysusers is less than a month old and has been part of a systemd release less than a week ago for the first time. If the only thing you could find is the user name length thing, the lack of updating of shadow and that we lack audit (which libuser also lacks), then I think we did a pretty good job so far... > > 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! > > I was not proposing to call the libuser command-line tools, so I don’t > think they are relevant. I agree it is not good that there are two > implementations, and as I already wrote, there is a plan (and people > assigned to it) to fix this. Well, the plans are vague, involve daemons and stuff, and from all I heard are really not the right thing for a minimalist early-boot tool like systemd-sysusers... > > 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. > > systemd has been happy to make so many different things de-facto > standard that I can’t see this being an outlier. Well, we can push stuff with systemd, sure, but it has to be convincing if we do it, we must be able to make a strong case. And quite frankly, you really didn't sell libuser so well, so far... I mean, you are even saying that it will go away... > > > 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? ;-) > > Because the glibc API is not at all the right one. (Way too low-level > as systemd-sysusers has successfully demonstrated; impossible to add > more fields; enshrines old bad design decisions, like having password > expiration in 24-hour granularity.) Considering the actual library > name is completely irrelevant, having the new API written and > maintained by people whose _primary occupation_ is to understand > accounts and identities seems like a good enough reason to have it > done by sssd maintainers, as a library included within that project. Well, you know, "systemd-sysusers", as the name says is a tool solely for registering system users. Sure, the glibc API might not be the best in the world, but it does do the basic bits that we need it to do just fine. And the thing about "primary occupation" I can only read that you are telling me to stay off your lawn, because I don't understand stuff. > And yes, the plan is to “get rid of libuser”, or rather to only have > it a shim layer over the new sssd API. I am sorry, but I really don't see system user registration in the early-boot as something I would ever entrust in a full flegded sssd-like thing. Please understand that we are not duplicating "adduser" here. Already in the name of the tool we wanted to make clear thtat this is abotu system users, nothing else. The file format we defined has been reduced to the minimum possible, in order to make it difficult for people to use it for anything else than this (for example, you cannot set a shell for a user with this, as system users are not suppoed to be logged into, unless the admin later on manually sets a password and a shell). An API that wants to implement a fully-featured "adduser" command of course needs to support backends for LDAP and stuff, no doubt. But this is really not that. We have a much much more limited usecase for what we do. We clarify that in name, and in the config file language we use. It's two different things. > > > 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. > > I would be perfectly happy if it called shadow-utils. That’s 200 kB > total, and definitely “commonly around on Linuxes”. Well, shadow-utils doesn't have a C API, and it's overkill for what we are doing, really. We just want to set up system users, with no passwords and with no login shells. It's not what we want. > Describing modularity, avoiding duplicate implementations, and keeping > specialized knowledge private to specialized modules as a “stacking > game” is not helping this discussion. Well, we need to solve a very simple problem with sysuers, and we have a very simple API for that in glibc, and hence it appears clearly the right decision for us to use glibc. I can see that you disagree, but I figure we have to agree to disagree on this. 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
