• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Authentication
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Authentication


  • Subject: Re: Authentication
  • From: Eric Peyton <email@hidden>
  • Date: Sun, 22 Jul 2001 12:06:32 -0500

On Sunday, July 22, 2001, at 11:07 AM, Finlay Dobbie wrote:


On Sunday, July 22, 2001, at 04:56 pm, Eric Peyton wrote:

NIAuthenticationPanel and the rest of NetInfoKit (NIAccess and NIInterface) are now considered Private SPI. If you are using them, you are doing so at your own risk and your application very well may break in the future.

The Public API for Authorization is the security framework.

1) Why? They have never been private since they were first created, and that's about 5 or 6 years, isn't it? I could be wrong, I never experienced NeXT.

I don't make the decisions, and I guarantee that the person who did is not on this list. Their decision and rational is valid in my opinion however. These are API's that Apple does not want to support long term on a shipping operating system. Every API that publically ships on OS X has to be supported indefinitely. This was one API that management felt did not need that support. You do not have to agree with this decision. Please file a bug if you feel differently.


2) So delete the documentation in /System/Library/PrivateFrameworks/NIInterface.framework/Versions/B/Resources/
English.lproj/Documentation and /System/Library/PrivateFrameworks/NIAccess.framework/Versions/B/Resources/
English.lproj/Documentation

Both are linked to from /Developer/Documentation/Cocoa/Reference


And we also need to delete the class files for NIAccess and NIInterface. These are both known issues. But the fact that the frameworks show up in /System/Library/**PRIVATE**Frameworks should have given a pretty good hint that they are private.

The problem I was having was that Security.framework was not giving me full root rights (i.e. it was euid 0 not uid 0), and I couldn't think of any other way of doing it than piping the password from an NIAuthenticationPanel to sudo. I could also have written a wrapper which runs getuid(0), it looks like, or used security.framework to execute sudo itself, but neither of those occurred to me.

The Security framework is the supported authentication and authorization framework for OS X.


Looks like the main reason for this is that Security.framework basically sucks, as I have stated before. Well, only when it comes the Authorization* commands, I guess. Is anybody at Apple working on addressing this problem?

I guarantee that there are people doing this. The Authorization API is very fresh and young, and includes an incredible amount of promise that the NI* frameworks never could come close to.

A couple of things to keep in mind.

a) NetInfo authentication is inherently limited and constrained by it's designed. You do NOT want this design as your system security model long term.

b) "Admin" authorization may mean significantly different things at some point in the future. It would be nice to be able to grant "printer admin" abilities to your son, but not "delete my disk admin" abilities. The extensible and clean Security/Authorization api is specifically for that kind of future granularity. NetInfo authentication could not support the planned extensions to security for the future (being based on group membership and all makes that kind of implementation exceedingly difficult)

c) The initial authorization API is not the be all, end all implementation. It was provided as a implementation to begin with. I do not know what kinds of improvements and features are planned immediately, but I do know that the security team is aware of these implementation deficiencies.

d) It's OPEN SOURCE! Go look for yourself. Fix problems. File bugs. Become the solution. (Of course, this isn't feasible for everyone, but if you have the free time ...)

e) The percentage of apple developers needing to do low level authorization is in actuality small. This is not an excuse, but a reality. I think most people would agree that spending significant time improving api's is a good thing, if you are not forgoing work on performance, tuning, bug fixing, etc. (Of course, your product needs

The potential is there, but the implementation is a bit screwy. Zombied processes, inability to control proceses spawned, and there isn't even an objective c wrapper!

File bugs. Just filing "it sucks" comments on public lists does no one any good (well only you if you really think that your fingers need the workout). There are lots of things that don't have ObjC wrappers. That will not change in the immediate future.

Eric

pah.

-- Finlay


  • Follow-Ups:
    • Re: Authentication
      • From: François Frisch <email@hidden>
    • Re: Authentication
      • From: Finlay Dobbie <email@hidden>
References: 
 >Re: Authentication (From: Finlay Dobbie <email@hidden>)

  • Prev by Date: Re: Authentication
  • Next by Date: Re: Authentication
  • Previous by thread: Re: Authentication
  • Next by thread: Re: Authentication
  • Index(es):
    • Date
    • Thread