topic Re: suid, sticky bit or setprivgrp? in Operating System - HP-UX

suid, sticky bit or setprivgrp?

TrustNo1 — Fri, 21 Mar 2003 15:40:36 GMT

I have done alot of reading on "suid, sticky bit and setprivgrp", but I'm having problems determining the correct path of action for the following.

Our cron controled batch schedule is run by the user "prodbat". At the moment "prodbat" is a member of the "csi" group only.
At some point in the schedule an Oracle backup must be performed by "prodbat" as the user Oracle by virtue of "group" rights.
The script has the following attributes; -rwxrwxr-- 1 m10000 dba 656 Feb 27 2002 script003

How can I make it so "prodbat" can do a suid to Oracle and run the script?

Thanks, ~jdk

Re: suid, sticky bit or setprivgrp?

Sridhar Bhaskarla — Fri, 21 Mar 2003 16:02:08 GMT

Hi,

You can accomplist it by setting an suid bit on the script. You will need to make sure the others have only execute permissions in order for a script to run as suid.

However, I would not suggest playing around with suid,sgid etc.,.

SUDO is a good tool that is so flexible that you can do what you want.

You can get it from HP's porting center

http://hpux.connect.org.uk/hppd/hpux/Sysadmin/sudo-1.6.6/

Look at the sudoers file man documentation for more details at

http://www.courtesan.com/sudo/

For ex., following in the sudoers file

sridhar myhost = (oracle) /home/oracle/scripts/shutdown_oracle

sridhar:>sudo -u oracle /home/oracle/scripts/shutdown_oracle

will allow me to run that script as oracle.

-Sri

Re: suid, sticky bit or setprivgrp?

Michael Steele_2 — Fri, 21 Mar 2003 17:52:32 GMT

Sticky bit is set on /tmp for all to use this is an example for you to consider. Do you want the world to have access? (* Hacker's dream *)

sticky bit:
chmod 1xxx /dir/file

rwxrwxrwt <== looks like Note the "t"

set gid:
chmod 2xxx /dir/file

rwxrwsrwx <== looks like Note the "s"

set uid:
chmod 4xxx /dir/file

rwsrwxrwx <=== looks like Note the "s"

Re: suid, sticky bit or setprivgrp?

TrustNo1 — Fri, 21 Mar 2003 19:25:23 GMT

Sidhar, the powers that be, don't care for the "sudo" idea, we've been down that road before and I lost.
Until now Ive been able to deal with id acceses through creative means.

M., I would like for the user "prodbat" to be able to execute a particular file as the user oracle (gid=dba).
Do I place the sticky bit on the group permissions of the file, then make "prodbat" a member of the that group?
Thanks, ~jdk

Re: suid, sticky bit or setprivgrp?

Michael Steele_2 — Fri, 21 Mar 2003 19:30:06 GMT

I think you want the setgid bit and not the sticky bit.

set gid:
chmod 2xxx /dir/file

This would satisfy:

"...Do I place the sticky bit on the group permissions of the file, then make "prodbat" a member of the that group?..."

Re: suid, sticky bit or setprivgrp?

Jeff Schussele — Fri, 21 Mar 2003 19:31:49 GMT

Hi,

Why don't you just add prodbat to the dba group?
Doesn't matter if dba is primary or secondary group for the prodbat user.
All you need is prodbat in the dba group.

My $0.02,
Jeff

Re: suid, sticky bit or setprivgrp?

Sridhar Bhaskarla — Fri, 21 Mar 2003 20:06:35 GMT

Hi Jdk,

I suggest the following *reluctantly* since you don't have any choice.

Yes. Create a seperate group (say prodgrp) with prodbat as only the member. On the file that is to be run as oracle, give *only* execute permission for prodbat and suid for oracle. It would look like this

#chgrp prodgrp /home/oracle/script
#chmod 4510 /home/oracle/script
#ll /home/oracle/script
-r-s--x--- 1 oracle prodgrp 1168 Jan 30 13:27 script

Keep monitoring the permissions on the script and the members in prodgrp group.

-Sri

Re: suid, sticky bit or setprivgrp?

TrustNo1 — Fri, 21 Mar 2003 21:03:08 GMT

OK, when the process runs, it runs as "prodbat", not oracle.
I think I need to be able do do the equuivilent to a "su" to oracle and execute the file without the password.
Does that sound right?

Thanks, ~jdk

Re: suid, sticky bit or setprivgrp?

Nesan — Fri, 21 Mar 2003 21:13:20 GMT

Just try including "prodbat" user into 'dba' group file as secondary group.
After including into group file,you can use 'newgrp' command to change effective group id.

Please see this example,

dmcspa 23: id
uid=168(omnioper) gid=20(users)
dmcspa 24: newgrp omniback
dmcspa 21: id
uid=168(omnioper) gid=109(omniback) groups=20(users)
dmcspa 22:

So before "prodbat" run backup , include the line
'newgrp dba' command ( it will create shell with dba group previlage. Next line run regular oracle backup command follows.

Reference from man pages

4000 (= u=s) Set user ID on file execution (file only)
2000 (= g=s) Set group ID on file execution (file only)

Add or delete the save-text-image-on-file- execution (sticky bit) permission. Useful only if u is expressed or implied in who.

Re: suid, sticky bit or setprivgrp?

Sridhar Bhaskarla — Fri, 21 Mar 2003 21:48:07 GMT

Hi Jdk,

No. If the permissions are looking like what I indicated, 'prodbat' can run this script directly and it will run as 'oracle' as it has the suid bit.

prodbat:>/home/oracle/script

I would not suggest you to add prodbat to dba group as it will open up permissions for this user for all the files that are group owned by dba. And that's the reason why I suggested to create a seperate group only for this purpose. This way only 'oracle' owns the file and only 'prodbat' executes it.

-Sri

Re: suid, sticky bit or setprivgrp?

TrustNo1 — Mon, 24 Mar 2003 18:32:02 GMT

Exceeeeelent answers guys! Now I more or less comprehend what it was I read in the man pages...jeeze I'm kinda' dense sometimes.
I do have a question, using Sridhar's example (thank goodness for test boxes), my test script "touches a file$$, then starts a "until flag=1" background process.
The new file is owned by "prodbat" and has "prodgrp" as the group as expected.
The background process owner is prodbat.
Thoughts?
Thanks,~jdk

Re: suid, sticky bit or setprivgrp?

Sridhar Bhaskarla — Mon, 24 Mar 2003 19:37:42 GMT

Hi Jdk,

You don't need a test box to try this.:-). Say you have access to two accounts you can play with it. accoutn1 and account2 are in the group mygrp.

account1:>pwd
/home/account1
account1:> cat sc
r
#!/usr/bin/ksh
touch /tmp/account1.file

account1:>chgrp mygrp scr
account1:>chmod 4510 scr
account1:>ll scr
-r-s--x--- 1 account1 mygrp Mar 24 13:00 scr
su - account2
account2:>/home/account1/scr
account2:> ll /tmp/account1.file
-rwx-r----- 1 account1 mygrp 0 Mar 24 13:01 /tmp/account1.file

The effective user id will become the owner of the file and hence it will run as account1. However, you will not be able to verify it through ps command.

However, you can mount the filesystems with nosuid option to disallow this.

-Sri

Re: suid, sticky bit or setprivgrp?

TrustNo1 — Tue, 25 Mar 2003 13:18:05 GMT

Sridhar,
Thanks for the clarification. If I could assign 12 points, I would.
It was the "ps" owner that had me.
The owner of the process is usefull information if I need to track it with measureware.

Thanks for all your assistance, ~jdk