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: Paul Berkowitz <email@hidden>
- Date: Sun, 25 Jul 2004 09:26:54 -0700
I got a bounce-back that my reply was too long (I quote a lot of Axel's
message). So I'm re-sending in two parts. The original may eventually turn
up after the weekend, if Chris E. lets it through - apologies for
duplication if that happens.
Paul
On 7/25/04 3:03 AM, "Axel Luttgens" <email@hidden> wrote:
Thanks, Axel, for all the attention to this. I'll reply inline.
>
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.
Yes, that's right.
>
>
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 ;-)
Here's the philosophical perspective. I have previously used
~/Library/Application Support without problems. This time I do want the app
(which will be shareware) to be useable by all users on the computer.
The practical aspect is that this procedure is connected with some routines
for entering a registration code. I'm in the - I guess - enviable situation
of having had previous shareware scripts pirated: I've been told of two
websites, a CD and a newsletter that have found my hidden files and a way to
"crack" them. I've dreamed up a very clever solution this time, which I
don't think will be crackable even for those who find the files, but it's
conflicting with my desire to let the app be used by more than one user. It
needs to compare data on disk with data in the app/script itself - if
there's only one copy of the app being used (say, from /Applications) having
the confirmation data scattered about in several user folders, while still
enforcing a limited date-defined free demo period, is tricky. Nevertheless,
I have now figured out a way to do it, so my initial problem has now become
moot. But I'm very glad for the knowledge you've provided - it will surely
be useful in the future.
>
>
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)
Actually, this didn't work for me in AppleScript. Using 'sudo' with 'do
shell script' of course just gets you the silly dialog about being careful
as result, but 'with administrator privileges' does bring up a dialog
requesting an admin password. That would have been fine with me - let an
administrator install while logged in as a non-admin user. That would have
been adequate. But it didn't work - I still got an error message about
insufficient permissions. That was with chmod. I didn't try chown.
>
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
OK, that's what I'll try next time, then restore correct ownership and
permissions when done. Thanks - this is useful. I'm still too new new to
Unix to have thought of this, so thanks for being so methodical.
>
>
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.
That would do, but I'd hope not to have to use 'su' from do shell script.
Furthermore, my script would not know the name of the admin - I'd have to
know the way to get the username(s) of the members of the admin group - is
that available to a regular user?
>
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.
Too messy.
>
>
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.)
I would be happy to leave that in the hands of the users. Either the admin
would install for the user while logged in as the regular user or (e.g.
members of the family) the user knows the admin password.
>
----- continued in part 2 -----
--
Paul Berkowitz
_______________________________________________
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.