From: bob@pta.pyramid.com.au (Bob Vernon)
Newsgroups: comp.sys.pyramid
Subject: Re: Weird problems with groups on Pyramid
Date: 10 Apr 92 00:23:50 GMT
Organization: Pyramid Technology Corporation, Sydney

In article <1872@wrdis01.af.mil> jshumate@wrdis01.af.mil (Shumate Jason) writes:
>I have been having some really weird problems with groups on Pyramid.  Let

So does everyone.  You are not alone.

>me explain.  I have a program that I want to run as setgid so that everyone
>in the group can have the permissions belonging to the owner.  Let's
>call my program "test" and say we have a group called "mygroup" that 
>is in /etc/groups that contains Mary, Joe, Jason.  The directory "test" is
>in has a permission of 777 all the way up the directory tree, so anyone
>on the system can reach it.  The directory looks like this:
>
>-rwxr-s---   Joe   mygroup   2000 test*
>
>In theory, all members of the group "mygroup" can execute test with the
>same permissions as Joe, right?

Maybe.  Maybe not.

>                                 Well, on my box, Joe can execute test,
>Jason can execute test, but Mary can't.  Absolute pathnames were used, and
>the  C-shell command "groups" shows Mary as being in the group, yet she
>can not execute test!

You didn't say what error message Mary gets, which would help a lot.
So I'll just list all the problems with the above that you may having
(from least likely to most likely).

1.  Is the name of your program really test?  There is a standard unix
program called test which (depending on your search path) may be
executing before your program called test.  In your case, you said you
were using absolute pathnames, so this isn't the problem.  But its
still not a good idea to call anything test.  Too much confusion.

2.  Is test a shell script?  If Joe and Jason are in a different
universe from Mary or use a different shell then it may be that a
different shell program is used to execute the script.  This will cause
differences in the way it executes.  You can usually force a script to
be executed by a specific shell by putting a #!/bin/att /bin/sh at the
top of of the script.  But there are exceptions to this (and I don't
want to get into that decision tree here).

3.  Again, is test a shell script?  For att sh in OSx5.0 and all the
shells in OSx5.1, suid and sgid are not honoured for any program that
is called by the shell script.  This is a security feature as any
suid/sgid script have security holes you can drive a truck through.
Nevertheless, some administrators are prepared to take the risk and
find it convenient to allow.  So your site may have installed an
unsecure version of the shell.  These are available but may have been
installed in only one universe or for one shell.  If Joe and Jason have
a different environment from Mary or use a different shell then it may
be that Mary is getting a secure shell and the boys are getting an
unsecure one.

4.  (This is the most likely).  Is Mary in the att universe?  If so
then do not use the groups command, use the att id command.  (BTW,
groups is not a C-shell command.  It is a ucb universe command
regardless of the shell).  In the standard SysV environment, a user is
in EXACTLY one group at any one time.  By default this is the group as
specified in your /etc/passwd entry.  If Mary is in the att universe
and her default group is not mygroup then she will not have permission
to execute your program.  She will have to execute the newgroup program
to switch to the mygroup alternative group.  She can then execute your
program.  Alternatively she can say ucb /path/test rather than just
/path/test.  This will then use the BSD groups convention rather than
the SysV convention.

>Has
>anyone else had a problem similar to mine?

All the time.  I'm someone who HATES BSD and try to avoid it whenever
possible.  But that means I have to put up with the hoop jumping that
the SysV group conventions force you into.  The way groups work in a
SysV environment is totally useless IMHO.  If you really need a lot of
groups and you want to run in the att universe, then set the kernel
flag ATTUCBGROUPS.  This is available in OSx5.1, can't remember if it
was in OSx5.1.  This means that the att universe will no longer be
compatible with a standard SysV environment, but what the heck.

>                                            I should add another Pyramid
>group problem that occurred - when the group "mygroup" was set up, our
>system refused to allow any members of the group "mygroup" execute the
>"test" program, so we changed the name of the group.  Magically, the group
>members could now execute "test", so we changed the name of the group back
>to "mygroup" and most of the users could still execute "test", with the
>exception of the above problem.

Possibly the difference between users logging on and off.  And also
related to what their default group is.  And whether you were reusing
group ids or changing them too.  Start with a fresh slate whenever you
are testing new groups.  That is, log the users off before doing
anything.

>                                 I figure either Pyramid has a problem
>that they need to catch and fix or I need to be educated out of my ignorance,
>so any help anyone can give would be greatly appreciated.

As the old saying goes "we don't have bugs, only features".  In this
case its really true.  Some people actually like the SysV groups
method so we have to make that way the default in the att universe.

>                                                      By the way, please
>don't suggest that I run my program with a permission of 750 and drop the
>setgid stuff.  For reason I don't want to go into, I want to run this program
>as setgid.  I assume that setting the permissions on the file to 2750 is
>all I have to do to run a program as setgid, assuming the right group is
>used.

Using sgid is fine for binary programs.  Try and avoid it for shell
scripts.  But setting the permissions is the easy part.  Getting the
groups to work is sometimes much harder.


Bob V!
--
      -m-------   Robert Vernon			  bob@pta.pyramid.com.au
    ---mmm-----   Pyramid Technology (Australia)
  -----mmmmm---   402 Pacific Highway		  PHONE: +61 2 901 5333
-------mmmmmmm-   Artarmon 2064 Australia	  FAX: +61 2 906 4353