Re: Running an App as Root
Re: Running an App as Root
- Subject: Re: Running an App as Root
- From: OL&L Dev 2 <email@hidden>
- Date: Tue, 4 Nov 2003 19:53:37 -0800
Actually there are several legitimate cases where you would want to
do root stuff silently - with caution of course. However, you *never*
want to do so in a user-level app without at least 1 authorization
prompt, or without the user logged in as root.
I do agree however that no end-user app should ever ship as setuid
root. That is why we have helper tools.
Having said that.......
1) It *is* allowable for one process to authorize one time, and then
have that process either share its AuthorizationRef with another
process, or else create shared credentials in the policy database
that can later be retrieved by either a helper tool or another
process.
2) Apple's Authorization for Al" Technote says that one allowable way
to do this is to have one app authorize, and if authorization
succeeds, then have that app create a right in the policy database
and then mark that right as "shared". Once the right is created as
shared, and another app goes to retrieve it, if it is marked as
shared, then the 2nd app will not throw the authorization dialog when
it calls AuthorizationCopyRights.
3) I have had to take this approach on a project in the past and
maybe my example will help: I did work on a project which had a UI
"user" app and then a second "engine" app. The UI app had to do
something requiring authorization, but then the engine (faceless) app
had to do something which also required authorization. The bad effect
for the user was that they saw 2 authorization dialogs even though
they only saw one app running. Not very nice. One solution was to
have the UI app do the inital authorization, then add a right to the
policy database which was marked as shared, then when it came time
for the 'engine' app to need authorization to do the root operation,
it simply requested the same right via AuthorizationCopyRights. Since
the right was already authorized, no second dialog appeared.
4) No matter what kind of user-level app you are shipping, it is
*never* unreasonable to ask for authorization *once* if the current
user is not logged in as root. It is however, unreasonable to prompt
the user more than once if it appears to them that only one app or
operation is taking place.
5) You should *always* prompt a non-root user for authorization at
least once in your app.
6) The correct approach as documented in Authorization for All is to
either create an AuthorizationRef and pass it between processes, or
else create shared rights in the policy database that both apps can
use - and thus still require on one authorization *prompt*.
James
At 8:45 PM -0600 11/4/03, Chris Hanson wrote:
On Nov 4, 2003, at 8:35 PM, David Blanton wrote:
Thanks for the solution.
What we need to do is 'silently' do some root stuff, i.e. Not present the
Authentication Panel to accomplish our goals.
Don't. Seriously.
The authentication panel is *important*. Making sure users know
that something risky is going on is *important*.
The technique demonstrated by AuthSample and MoreAuthSample
minimizes the number of times the authentication panel comes up. In
typical use, the user should only see it once, the first time they
try to perform an action that requires authorization. Because the
helper tool will configure itself to be setuid-root (and will check
the authorization ID it's passed before performing any actions),
subsequent runs of the tool will no longer show the authorization
panel.
Well see about flipping some bits somewhere.
Don't. Please. No end-user Cocoa application should *ever* ship
setuid-root, which is what it sounds like you want to do. Shipping
an application that way is a big security hole.
This is why I said it's extremely important to know exactly how
AuthSample and MoreAuthSample work before jumping into your own
code. Since you're talking about "flipping some bits somewhere" it
looks like you haven't taken the time to do that. (It looks like
you just said "Authorization dialog? No way! Let's just be setuid
root then.") Read and understand AuthSample and MoreAuthSample
before you even *think* of writing another line of code. Your users
-- and their security -- will thank you.
-- Chris
--
Chris Hanson, bDistributed.com, Inc. | Email: email@hidden
Outsourcing Vendor Evaluation | Phone: +1-847-372-3955
Custom Mac OS X Development | Fax: +1-847-589-3738
http://bdistributed.com/ | Personal Email: email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.