Very Computer

>         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

> 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

>Thanks in advance,

>Tom

>   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.

>>   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.