On Mon, Jun 11, 2001 at 06:35:02PM -0400, Adam Slattery wrote: > > Don't get so ambitious. Name services should be mostly read-only. There > > are too many different backend possibilities to be able to write a > > generic write API for name services(*). There's no puthostent(), and not > > just because DNS updates haven't been available till recently. > > > > There's a lot to think about, and I would rather there were no standard > > write-side API for name services. I'm a sysadmin -- I know how difficult > > name space management can be -- most shops build tools and scripts to > > match their problems and goals. Solutions are needed, but I think they > > should be product-specific, not standard, otherwise I'm afraid we'd get > > stuck with a bad standard. Ever look at XFN? > > I think you are wrong here. There should be a generic write API. Of > course, it must be modular. I'm not sure if you were taking that fact into > consideration. Name space management can be difficult, and I strongly > feel that a read-write API would simplify it more than a read-only API. > > IMHO, having the ability to both retrieve and set (read-write) user > attributes (shell, home directory, uid, gid, etc) would provide much > greater flexibility than a read-only API. The biggest problem is this: whereas a read-only API can be generic enough to apply different name services and data models with rather little pain, the same is NOT true of write APIs. Don't get stuck with a NIS or LDAP view of the world. Some systems support, even require transactions. Some model data in interesting ways; translating to a user/attribute/value model for reading is usually not hard, but translating back can be. PAM is not an administration interface. Neither is NSS. I want to replace NSS with a more generic interface, but still read-only. It's a much easier way to start than would be designing a read-write replacement API. Also, I only want to integrate a getpwnam() replacement API with PAM, not necessarily all of NSS. Then too, many sysadmins would prefer to access the name service more directly than through some generic name service independent API, so designing such an API would be for naught. Finally, look at XFN and what a crummy API that was. That's what you get when you try to address the write-side of things generically. > Well, I think the second prototype would fit into PAM better (going mainly > by pam_get_item()). This way, the application can request the attribute > it needs directly. Multiple values probably aren't required, but I'm not > sure. Really? What about the groups that a user belongs to? > > And so on. But then, you also gotta think about the SPI (i.e., the > > interfaces exported by the modules to implement this), including > > stackability considerations (i.e., what's it mean to have multiple > > modules that know different values of a given attribute for the same > > user. And then you need a standard set of attributes to replace > > getpwnam() with, a standard set of attrs to extend getpwnam() with, > > etc... > > Stackability isn't really an issue. If differant "required" modules have > differant information, return failure. Certainly it would take some > planning on the administrator's part to set this up correctly if he/she > wanted to stack this type of module, but it really wouldn't be a problem. Then why have a stack? I think stackability may well be an issue. But I'm not sure about the semantics of lookup stackability, yet. > Yes, we would need to decide on a standard set of attributes. Everything > getpwnam() provides should be sufficient; I can't think of anything else > that would be needed by the application, but additional attributes could > be transparently added if we used the second prototype above. It is precisely because getpwnam() does not provide enough attributes that I want to replace it. There's lots of things that an app, and more importantly, PAM *modules*, might need. E.g., login enabled/disabled status, hours during which the user can login, groups the user belongs to, _netgroups_ the user belongs to, and other authorization data. Don't tell me to stuff that into the GECOS field of passwd entries. I wouldn't bother if that were enough. And don't tell me that replacing the crypted password or shell fields is enough to mark a user as disabled (think of Samba, which checks neither in some setups). > Now, here is another hypothetical problem that is identical to the problem > I was facing with pam_crypt. How do authentication modules obtain these > attributes? Using this very API. > The main attributes that authentication modules would need are the hashed > token (password) and account expiration information. Coincidentally, these > are the things in /etc/shadow. Stop thinking crypt() for a minute. There's other authentication mechanisms. /etc/shadow is useless if I'm using Kerberos. > The authentication modules would rely on PAM to obtain these attributes. > We can probably do this (for the module) in one of two ways. Either add a > pam_get_item() feature, or create a new call solely for dealing with these > authentication attributes. It would probably be much simpler and much > better to add things to pam_get_item(). But that would not be extensible. > Another issue that would arrise is the fact that in order to authenticate > a user, not only must the authentication stack succeed, but the "user > attribute" stack must also succeed if the authentication stack needs > information from the "user attribute" stack. Why? If the modules use this API then they'll know when a missing attribute should lead to module failure. > > - Adam Slattery Nico --
