Date: Sun, 27 Jan 2002 13:19:41 +0000 From: Scott Mitchell <scott.mitchell@mail.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-hackers@freebsd.org Subject: Re: PAM, setusercontext, kdm and ports/32273 Message-ID: <20020127131941.C295@localhost> In-Reply-To: <3C53F08E.66E3E4D5@mindspring.com>; from tlambert2@mindspring.com on Sun, Jan 27, 2002 at 04:20:30AM -0800 References: <20020126224243.A72777@localhost> <3C534F33.2755EED9@mindspring.com> <20020127115514.A295@localhost> <3C53F08E.66E3E4D5@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 27, 2002 at 04:20:30AM -0800, Terry Lambert wrote: > Scott Mitchell wrote: > > 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 adds some additional, optional behaviour that you can choose to turn on for those cases that would benefit from it... I wasn't suggesting that it become any kind of default. > 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. Fair enough -- I agree with all that in general. In this case, though, surely kdm is going to be exposed to unknown side effects from its use of PAM anyway... I'll accept that there might be bad interactions between PAM and setusercontext() that I haven't considered. I'm not familiar enough with PAM to know what those would be. > Basically, xdm demonstrates that the problem is that > kdm is using the interface wrong, and should be changed > to do what xdm does. xdm demonstrates that it was easy to hack to exhibit the desired behaviour, not necessarily that it's the right way to do it. In any case, hacking kdm is considerably less work, so I might as well do that first. Scott -- =========================================================================== Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines" scott.mitchell@mail.com | 0xAA775B8B | -- Anon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020127131941.C295>