2

Why doesn't glibc provide standard library to modify /etc/passwd and /etc/shadow, i.e add a user, change passwd,

I came to that conclusion because I checked the source code of shadow and failed to find such interface

Improve this question

3 Answers 3

Reset to default
3

Because it's not glibc's responsibility. glibc delegates to other services installed on the system for auth; if anything it would be those that would provide the ability to modify the userdb.

Improve this answer
1
  • -1: getpwnam(3) and friends live in glibc. If setpwnam(3) and such existed, why wouldn't they live there, too? Granted, these may well just be interfaces to other mechanisms, but from the programmer's perspective, they get these facilities from glibc. It's not a question of responsibility. It's a question of the reverse mapping the OP wants being far from trivial, so if someone did create a library that did this, its API would be a colossal mess.
    – Warren Young
    Commented Jan 8, 2013 at 18:39
3

You're starting with an assumption here, which is that /etc/{passwd,shadow,group} is always the single point of truth (SPOT) for user information on Unix boxes. That hasn't been true since the mid-1980s, when Sun introduced NIS.

The reverse case APIs do exist: getpwnam(3) and friends. If your site's SPOT for user data is an LDAP server, it's easy to see how you would reduce its rich output to show only those things that exist in /etc/{passwd,shadow}.

But, you want an API that does the reverse. How would you implement setpwnam(3) in a world where you don't know if the back-end data store is /etc/*, or NIS, or NIS+, or LDAP, or ActiveDirectory, or...? You can filter krill from an ocean, but you can't get cubic meters of ocean from a bucketful of krill.

Improve this answer
5
  • You'd implement it through NSS, just like getpwnam. Some backends would support it (e.g., files), some would not (e.g., ldap). I suspect the real answer is that a simplified interface isn't actually useful to much anyone.
    – derobert
    Commented Jan 8, 2013 at 19:03
  • @derobert: It seems you're talking about a function that would only be useful for modifying /etc/*, which is not at all what nsswitch is for. Its point is to do the "krill filtering" operation: pull requested info from a configurable series of places and present it in a common form. If there were an inverse nsswitch, its API would have to have all the functionality you find in libldap, nis_*(), etc. I've programmed using libldap...it's far from simple. Now create an API that has to be able to take information suitable for popupating not just LDAP, but also NIS+, AD...<shudder>
    – Warren Young
    Commented Jan 8, 2013 at 19:24
  • If there was a big enough demand for wanting the functionality of changing, e.g., home directory, shell, uid, gid, that'd be fairly reasonable to do for files, nis, ldap, etc. (gecos would be almost impossible, and no one uses pw_passwd for real anymore, and PAM already handles that) But of course, a program that wants to do that, actually wants to do all kinds of stuff with that LDAP user. So there isn't really a demand for the simplified API (and the threshold to get it into libc is pretty high). I think that's why it doesn't exist, not that its really hard to build.
    – derobert
    Commented Jan 8, 2013 at 19:28
  • @derobert: Tell you what, go read this book, then come back and tell me how easy it would be to create such an API. (Yes, I've already read it, and I can tell you it's actually quite outdated. The real situation in 2013 is even more complex.)
    – Warren Young
    Commented Jan 8, 2013 at 19:31
  • So, I actually run LDAP users on our Linux boxes here—and yes, you certain can and do have LDAP systems where "change the shell field" might be hard, even meaningless. Maybe its even common on very large setups (which I confess I'm not familiar with) But so what? getpwnam isn't a perfect abstraction, either. E.g., take a look a PAM. It abstracts "change password". Does that work on every LDAP setup? No. But its still useful on the setups it does work on. But I guess if we want to continue this, we should use chat.
    – derobert
    Commented Jan 8, 2013 at 20:02
1

Simple answer if you think about it, there can be no C standard library to interact with them, simply because they are not C standard features. How would this work on windows?

Improve this answer
3
  • This answer is as straight to the point as you can get. Even if that weren't the case, adding a user to passwd or shadow takes on entirely different logic paths when you start messing with /etc/nsswitch.conf. Especially when the same uid is defined in multiple nsswitch databases.
    – Andrew B
    Commented Jan 8, 2013 at 6:47
  • 3
    Little of POSIX is C standard features, yet glibc implements a large portion of it.
    – Ignacio Vazquez-Abrams
    Commented Jan 8, 2013 at 9:52
  • @IgnacioVazquez-Abrams good point. Is the passwd/shadow system considered standardized? Posix or otherwise?
    – Karthik T
    Commented Jan 8, 2013 at 10:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .