Re: Making folders and files as non-admin user [WAS: Re: Privileged shutdown]
Re: Making folders and files as non-admin user [WAS: Re: Privileged shutdown]
- Subject: Re: Making folders and files as non-admin user [WAS: Re: Privileged shutdown]
- From: Axel Luttgens <email@hidden>
- Date: Sun, 25 Jul 2004 12:03:55 +0200
Paul Berkowitz wrote:
On 7/24/04 6:46 AM, "Axel Luttgens" <email@hidden> wrote:
[...]
A related question. I want my script (actually an AS-S app) to create a
folder and a file in /Library/Application Support/. But when logged in as a
standard, non-admin user, it doesn't have permission. I suppose that's
understandable.
The best solution to this is if I could throw up a dialog asking for an
admin name and password, like you see when doing very sorts of installing in
non-admin users. [...]
Has anyone gone this route before? Creating a folder and file in
/Library/Application Support/ or just /Library when in a non-admin user? Is
there an easy way?
My script first tries to get the Finder to do it and, on error , do shell
script "mkdir" . Both fail.
The authorizations of '/Library/Application Support':
drwxrwxr-x 19 root admin 646 24 Jun 13:48 Application Support
clearly indicate the intents: only administrators should be able to add
or remove items in that folder.
This raises a first question: does your application really need to
install things in such system folders?
After all, there is a ~/Library folder in a user's home directory, as
well as one could create an ~/Applications folder in that directory too.
Putting data in the system-level '/Library/Application Support' would
only make sense if one needed that data to be shared amongst multiple
users on the computer.
Is your application to be used by multiple users on a same computer, or
fundamentally targeted to the specific needs of a single user? [1]
Ok, that was for the philosopical perspective ;-)
First, a recap of what happens at the BSD level.
(and please forgive me for the obvious things I am very likely going to
write in my attempt to be somewhat systematic)
If one had to create a folder in '/Library/Application Support' from the
unix layer (assuming it is the current directory):
a) I am running as a user belonging the group admin; given the enclosing
folder's auths, no problem:
mkdir testfolder
--> drwxr-xr-x 2 luttgens admin 68 25 Jul 09:25 testfolder
Note that this doesn't rely on the specifics of group admin at all; this
works just because the enclosing folder allows members of a given group
(here, admin) to create items.
If I wanted everybody to be able to write into testfolder, as I am the
owner of that folder, I may write:
chmod go+w testfolder
--> drwxrwxrwx 2 luttgens admin 68 25 Jul 09:25 testfolder
Something else would be to make testfolder owned by root (for whatever
reason)
As BSD doesn't allow to throw away file ownership, I need the power of
the root user; fortunately, I am member of group admin, so that I can
invoke sudo (because of its default configuration, allowing any member
of group admin to perform any operation as root) [2]:
sudo chown root testfolder
Password: <enter luttgens' password here>
--> drwxrwxrwx 2 root admin 68 25 Jul 09:25 testfolder
b) I am running as a regular user (say user 'test' of group 'test'):
mkdir testfolder
--> permission denied
That was to be expected...
Now, if I know luttgens' password, I can do:
su luttgens
Password: <enter luttgens' password here>
mkdir testfolder
--> drwxr-xr-x 2 luttgens admin 68 25 Jul 09:30 testfolder
exit
As a result, it appears that I need either to already be logged in as an
administrator, or to know an administrator's user name/password.
One could think of some workarounds: modify the sudoers authorization
schemes, create and install a setuid application...
But such things need an administrator's user name/password too.
The morality is that, should one want to allow a regular user to make
HIMSELF changes at system places, one MUST provide him with the power of
an administrator.
Not an easy decision, especially if you know that your regular user is a
very clumsy one...
(Things would of course be different if you could rely on the
preliminary intervention of an administrator.)
Now, let's have a look at the Mac OS layer.
As far as file system operations are concerned, and because it relies on
the BSD layer, it can't contradict the latter.
And certainly not be more permissive.
In fact, it often tends to be more stringent than BSD; just enable the
root user and log in as that user: you will become very frustrated...
So, let's log in as our regular user 'test', create a folder named
'testfolder' on the desktop, open the window of '/Library/Application
Support' and drag 'testfolder' to that window.
A dialog box immediately appears, telling us that we just aren't allowed
to do this (how could we dare?!?).
But there's an 'Authenticate' button. [3]
Which allows you to enter an... administrator name/password.
In fact, the Mac OS layer adds its own authorization policy over the BSD
layer's one.
To get an quick idea about it, just look at the contents of:
/etc/authorization
It appears that the group 'admin' receives a special treatment too (the
same way members of that group receive lots of privileges through sudo
at the BSD level).
All those matters are developed in:
<
http://developer.apple.com/documentation/Security/Conceptual/authorization_concepts/index.html>
As you are considering an AS-S application [4], and should you really
need to install things into system locations, it should be possible to
implement something similar to what is described in the section "Calling
a Privileged Installer"
Sorry for the length,
And hoping to be of some help,
Axel
[1] Incidentally, I always feel unconfortable with the choices behind
the OS installer: the user who installs the OS also becomes an
administrator, with nothing in the procedure leading to the creation of
a regular user's account.
As a result, every Mac OS computer in the world is very likely to be run
in an unsecure way.
[2] But what's the magic about 'sudo'?
In fact, it is an executable owned by root, with it set uid bit set, and
executable by everyone.
So, somebody running 'sudo <some command>' launches sudo as root, so
that sudo then has the ability to transfer its privileges to other
processes.
This of course supposes that sudo is bug-free...
But this also is possible because somebody having root privileges must
have created/installed sudo. Kind of chicken-egg, isn't it?
[3] It's only rather recently that such authentication buttons are
systematically provided in the various parts of the Finder's interface.
[4] Tell me, why did you put an hypen? ;-)
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.