Scott Mitchell wrote: > > > However, this got me thinking -- is the right solution here to have a PAM > > > module that does the setusercontext(), so programs that already know about > > > PAM will just work, without needing to know about setusercontext() as well? > > > I can see that causing problems with programs (login, xdm, etc.) that > > > already understand both mechanisms, but they could always not use this > > > hypothetical pam_setusercontext module, right? > > > > > > So, is this a worthwhile thing to have? I'm happy to either write the PAM > > > module or fix kdm, but I'd rather not waste my time learning about PAM > > > internals if people think this would be a pointless exercise. > > > > No. THis is a bad idea. Fix KDM instead. > > OK, but could you explain *why* you think it's a bad idea?
It adds a side effect that wasn't there before in order to work around an improper usage of an interface. It's very bad to add a side effect that changes the API behaviour into a platform dependent API behaviour. It's very bad to have side effects, even if they are documented (look at the effort that is currently going into wedging an error return value into the external global "errno" for strtod()'s "0.0" case, in another thread). It's very bad to add a complex behaviour that can be aggregated out of a set of simple behaviours, instead. It's bad to change an abstraction layer; it's possible for a program to want to avoid the side effect, and find itself unable to do so, as well, which would mean that the interface abstraction itself was damaged by the change. Basically, xdm demonstrates that the problem is that kdm is using the interface wrong, and should be changed to do what xdm does. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
