panisset@thunder.mcrcim.mcgill.edu (Jean-Francois Panisset ) (04/27/91)
Here is a question from an Aegis novice: I am trying to create scripts
which are to run setuid to root, and things are not working (we are
running Domain 10.2, btw). Here is what I am trying to do:
1. Create a directory called lock_dir
2. remove any rights to others except root. The resulting ACL is:
Acl for lock_dir:
Required entries:
root.%.% prwx-
%.psram.% -----
%.%.inc [ingnored]
%.%.% -----
Extended entry rights mask: -----
3. Create a script called root_script containing the following line:
edacl lock_dir -a yourself prwx
4. Make root the owner of the script (if it is not already):
edacl root_script -prwx
5. Set the setuid bit on for root_script:
edacl root_script -setuid on
6. By now, the ACL for root_script should look like:
Acl for lock_dir:
Required entries:
root.%.% prwx- set person
%.psram.% prwx-
%.%.inc [ingnored]
%.%.% prwx-
Extended entry rights mask: -----
7. Now, go back to yourself and try:
% root_script
Error: no rights to change acl - "lock_dir"
So what is the problem? It seems that my setuid script does not run as
root? Am I missing something here, or am I making a UNIX-like assumption
about Aegis?
Thanks in advance to all you Aegis gurus out there...
JF Panisset
--
Jean-Francois Panisset
INET: panisset@mcrcim.mcgill.ca
panisset@larry.mcrcim.mcgill.edu
UUCP: ...!mcgill-vision!panisset nazgul@alphalpha.com (Kee Hinckley) (04/28/91)
In article <1991Apr26.220353.22998@thunder.mcrcim.mcgill.edu> panisset@thunder.mcrcim.mcgill.edu (Jean-Francois Panisset ) writes: >edacl lock_dir -a yourself prwx Of course all I have to do is change my path, create a command called edacl in it which runs a shell, and boom - I'm root. Fortunately you don't have to worry about this :-). Aegis doesn't support setuid scripts. -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
rtb@cernapo.cern.ch (Rainer Tobbicke) (04/28/91)
panisset@thunder.mcrcim.mcgill.edu (Jean-Francois Panisset ) writes: >Here is a question from an Aegis novice: I am trying to create scripts >which are to run setuid to root, and things are not working (we are >5. Set the setuid bit on for root_script: >edacl root_script -setuid on >Error: no rights to change acl - "lock_dir" It is not clear to me which shell you use, probably /com/sh since you seem to prefer the Aegis version of the acl handling commands. But it seems that you run into the same problem you would have using the chacl command: the -s option (-setuid on in your case) changes the effective userid. Your script would have to set the real userid, like a setuid program does, i.e. setuid(geteuid()). I'm not aware of a shell that does that (although the story sounds familiar since the suid_exec 'scandal' last year, and I vaguely remember that having something to do with ksh). -- Rainer Toebbicke European Organisation for Nuclear Research (CERN) Geneva, Switzerland rtb@cernapo.cern.ch, rtb@cernvm.cern.ch
etb@milton.u.washington.edu (Eric Bushnell) (04/29/91)
In article <1991Apr26.220353.22998@thunder.mcrcim.mcgill.edu> panisset@thunder.mcrcim.mcgill.edu (Jean-Francois Panisset ) writes: >Here is a question from an Aegis novice: I am trying to create scripts >which are to run setuid to root, and things are not working (we are >running Domain 10.2, btw). Here is what I am trying to do: > When I once succumbed to the temptation to write an SUID-root shell script on a 10.3 node, I discovered that it didn't really change the UID. I presume this is a security feature. It's one feature I won't carp about. Root scripts can be dangerous, and it saved me from ignoring my better judgment. 8-} -- Eric Bushnell Univ of Washington Civil Engineering etb@u.washington.edu