What is an SUID? When can I use it?

What is an SUID? When can I use it?

Post by Tom » Wed, 22 Sep 1999 04:00:00



        I have a few users that are in the "Sybase" group. The Sybase admin wants
them out. I have to create a new (lower) group and move them into it making
sure that they can execute the programs they did before, but not be able to
administer as the sybase group is.  Is this where suid comes into play? Can
someone explain it further to me? These people are pissed that I have to
make the changes but, I don't have a choice.

Thanks in advance,

Tom

 
 
 

What is an SUID? When can I use it?

Post by Terry Mummer » Wed, 22 Sep 1999 04:00:00


Tom,

From memory,
SetUId (suid) is a permissions setting on an executable file (Do NOT put
it on a shell script or you open yourself to being hacked). If the file
has execute permissions for a given user, when they execute the file,
they do so as though they were the user that 'owns' the file.

e.g. myfile with permissions 4755  root  sys   myfile.

if I were user tom and executed myfile then myfile would be executed as
though root had invoked it. (you can see the danger if not strictly
controlled).

 Another option you might like to check out is sudo this gives a limited
su to root facility to normal users.
Terry Mummery


>         I have a few users that are in the "Sybase" group. The Sybase admin wants
> them out. I have to create a new (lower) group and move them into it making
> sure that they can execute the programs they did before, but not be able to
> administer as the sybase group is.  Is this where suid comes into play? Can
> someone explain it further to me? These people are pissed that I have to
> make the changes but, I don't have a choice.

> Thanks in advance,

> Tom


 
 
 

What is an SUID? When can I use it?

Post by jamm.. » Thu, 23 Sep 1999 04:00:00


on AIX (and other UNIXes as well), SUID (or SGID for groups) is ignored
for shell-scripts. you have to wrote a wrapper c-prg (oder use perl,
there are SUID features for perl scripts)



> Tom,

> From memory,
> SetUId (suid) is a permissions setting on an executable file (Do NOT
put
> it on a shell script or you open yourself to being hacked). If the
file
> has execute permissions for a given user, when they execute the file,
> they do so as though they were the user that 'owns' the file.

> e.g. myfile with permissions 4755  root  sys   myfile.

> if I were user tom and executed myfile then myfile would be executed
as
> though root had invoked it. (you can see the danger if not strictly
> controlled).

>  Another option you might like to check out is sudo this gives a
limited
> su to root facility to normal users.
> Terry Mummery


> >         I have a few users that are in the "Sybase" group. The
Sybase admin wants
> > them out. I have to create a new (lower) group and move them into
it making
> > sure that they can execute the programs they did before, but not be
able to
> > administer as the sybase group is.  Is this where suid comes into
play? Can
> > someone explain it further to me? These people are pissed that I
have to
> > make the changes but, I don't have a choice.

> > Thanks in advance,

> > Tom

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
 
 
 

What is an SUID? When can I use it?

Post by John Jaszcza » Thu, 23 Sep 1999 04:00:00


  If I understand you correctly, you are saying that the users must still be
able to execute the sybase scripts/programs but should not be permitted to
modify them. If that is the case, then you need only ensure that the execute
permissions for the scripts/programs are granted to "other" (o+x).
  If these users are currently in the sybase group, then create a new group
or choose a different existing group and for each user run the command
find / -user <userid> -exec chgrp <new group> {} \;
This will ghange the group of all files this user currently owns (so they
can still modify their own stuff) If sybase was the only group the users
belonged to, then you will have to change the group using some like:
chuser pgrp=<new group> userid
You will also want to do this if the users primary group was sybase.
Then you can merely remove the users from the sybase group.

-JAZZ
--
John Jaszczak
Romac International
Assigned to: Harmonic Systems, Inc.

612-321-4139


> I have a few users that are in the "Sybase" group. The Sybase admin wants
>them out. I have to create a new (lower) group and move them into it making
>sure that they can execute the programs they did before, but not be able to
>administer as the sybase group is.  Is this where suid comes into play? Can
>someone explain it further to me? These people are pissed that I have to
>make the changes but, I don't have a choice.

>Thanks in advance,

>Tom

 
 
 

What is an SUID? When can I use it?

Post by Norman Levi » Fri, 24 Sep 1999 04:00:00



>   If I understand you correctly, you are saying that the users must still be
> able to execute the sybase scripts/programs but should not be permitted to
> modify them. If that is the case, then you need only ensure that the execute
> permissions for the scripts/programs are granted to "other" (o+x).
>   If these users are currently in the sybase group, then create a new group
> or choose a different existing group and for each user run the command
> find / -user <userid> -exec chgrp <new group> {} \;
> This will ghange the group of all files this user currently owns (so they
> can still modify their own stuff) If sybase was the only group the users
> belonged to, then you will have to change the group using some like:
> chuser pgrp=<new group> userid
> You will also want to do this if the users primary group was sybase.
> Then you can merely remove the users from the sybase group.

> -JAZZ
> --
> John Jaszczak
> Romac International
> Assigned to: Harmonic Systems, Inc.

> 612-321-4139


> > I have a few users that are in the "Sybase" group. The Sybase admin wants
> >them out. I have to create a new (lower) group and move them into it making
> >sure that they can execute the programs they did before, but not be able to
> >administer as the sybase group is.

*** Look into Access Control Lists.
Move your people OUT of the sybase group and move them into a group
your create, say SYBASEX
Then, using ACLEDIT, add an extended permission to the programs you
want them to run.
First
export EDITOR=/usr/bin/vi # must be full path
acledit sybase-pgm
You will have an ascii display.
Change
Extended Permissions
Disabled >> to Enabled
then add
permit --x g:sybasex
and :wq

--
Norman Levin
vm/dynAmIX inc.

 
 
 

What is an SUID? When can I use it?

Post by John Jaszcza » Fri, 24 Sep 1999 04:00:00


  As you can see there are many ways to address this situation. I do recall
something about mksysb losing the ACL attributes of files. Or is that simply
the backup command that lost the ACL attributes?
Someone, anyone?

-JAZZ

--
John Jaszczak
Romac International
Assigned to: Harmonic Systems, Inc.

612-321-4139



>>   If I understand you correctly, you are saying that the users must still
be
>> able to execute the sybase scripts/programs but should not be permitted
to
>> modify them. If that is the case, then you need only ensure that the
execute
>> permissions for the scripts/programs are granted to "other" (o+x).
>>   If these users are currently in the sybase group, then create a new
group
>> or choose a different existing group and for each user run the command
>> find / -user <userid> -exec chgrp <new group> {} \;
>> This will ghange the group of all files this user currently owns (so they
>> can still modify their own stuff) If sybase was the only group the users
>> belonged to, then you will have to change the group using some like:
>> chuser pgrp=<new group> userid
>> You will also want to do this if the users primary group was sybase.
>> Then you can merely remove the users from the sybase group.

>> -JAZZ
>> --
>> John Jaszczak
>> Romac International
>> Assigned to: Harmonic Systems, Inc.

>> 612-321-4139


>> > I have a few users that are in the "Sybase" group. The Sybase admin
wants
>> >them out. I have to create a new (lower) group and move them into it
making
>> >sure that they can execute the programs they did before, but not be able
to
>> >administer as the sybase group is.
>*** Look into Access Control Lists.
>Move your people OUT of the sybase group and move them into a group
>your create, say SYBASEX
>Then, using ACLEDIT, add an extended permission to the programs you
>want them to run.
>First
>export EDITOR=/usr/bin/vi # must be full path
>acledit sybase-pgm
>You will have an ascii display.
>Change
>Extended Permissions
>Disabled >> to Enabled
>then add
>permit --x g:sybasex
>and :wq

>--
>Norman Levin
>vm/dynAmIX inc.