Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: darwin-development digest, Vol 3 #574 - 10 msgs

At 4:25 PM -0700 12/4/02, David M. Williams wrote:
Henry B. Hotz wrote:

That still leaves the screen saver. What does it do with passwords, and how do I make it do the same as the other two mechanisms?

A less than trivial concern for sites that want to run all authentication through Kerberos, local accounts for emegencies only. I've dug around the documentation for screensaver but didn't see anything on the where and how of it's authentication process.

As someone else pointed out there is a fourth authentication query type that is done by installers and e.g. System Preferences.

I think I disagree with having PAM call the security framework. If there is to be any hope of leveraging off of existing open source implementations then PAM should be usable by all three of the authentication routes I mentioned.

I am in agreement with Henry here. It was my impression from reading the docs that this was the intent when PAM support was added.

Thanks for the support.

There are comments in the Darwin code that make that pretty clear. The intent didn't survive a high-level review, clearly. I can guess from what JH said that part of the problem is that the security framework is a "bigger" API than PAM and therefore it really only works in the direction that is implemented. You can throw information away, but you can't create it.

Apple needs to better address the issue or people like us will continue to be unhappy.

The alternative would be to provide a generic security framework wrapper for PAM code so it can be ported trivially by programmers ignorant of the security framework.

I hope that I made my point that it's a security problem if it isn't easy to make all the different authentication paths the same (or different in only obvious ways). Furthermore silly/obvious changes like s/security/pam/ are tolerable while radical/obscure changes like "screen saver ignores PAM" are not.

<nit>
I think it's better to have stuff in /usr/{include,lib}/pam/ than in /usr/{include,lib}/security/. Using the name /security/ is overblown and uninformative. Also changing it in open source code is something that can be done by "programmers ignorant of the security framework".
</nit>

<My $.02> I did not file the bug report about PAM's {include,lib} location because I think the name "security" is in anyway better than "pam". Neither did I file it because I can't/won't port my code to support the new location (I already have). I filed the bug because the world needs another vendor doing things "different" like I need a call from the IRS. This is about portability and compliance to standards, be they IETF or de facto. Right now PAM isn't that tightly integrated so moving the PAM stuff shouldn't be that great a burden, IMHO.
</My $.02>

It bothers me more that /etc/krb5.conf got moved to /Library/Preferences/edu.mit.Kerberos, and there's no man page. Since I'm new to PAM I'm more bothered by the pretentious use of "security" vice "pam" than some. Since Solaris and Linux (and FreeBSD?) use "security" I suppose that does constitute a real de facto standard.

Did you in fact create a pam_krb5 that works on Jaguar? I've run into some strange linking issues trying to to that myself.
--
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
email@hidden, or email@hidden
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: darwin-development digest, Vol 3 #574 - 10 msgs (From: "Henry B. Hotz" <email@hidden>)
 >Re: darwin-development digest, Vol 3 #574 - 10 msgs (From: "David M. Williams" <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.