[OpenAFS] correct usage of supergroups

[Marcus Watts]

scorch <scorch@muse.net.nz> writes:

> Message-ID: <434AF32F.8030105@muse.net.nz>
> From: scorch <scorch@muse.net.nz>
> To: openafs-info@openafs.org
> Subject: [OpenAFS] correct usage of supergroups
> Date: Tue, 11 Oct 2005 01:03:11 +0200
> 
> dear AFSers
> 
> I have some questions about supergroup functionality. I'd expected that 
> I can create the following:
> 
> Access list for /afs/.muse.net.nz/pub/images is
> Normal rights:
>    write:images rlidwk
>    admin:images rlidwka
>    read:images rl
> 
> this mirrors how security is currently set up on a large windows 
> environment. it helps migrating the permissions via script & keeping the 
> existing controls of who can change permissions in place - users can 
> control the membership of groups, but not the permissions themselves.
> 
> and then have membership of each group as follows:
> $ pts mem admin:images
> Members of admin:images (id: -212) are:
>    system:administrators
> 
> $ pts mem read:images
> Members of read:images (id: -211) are:
>    system:anyuser
> 
> $ pts mem write:images
> Members of write:images (id: -213) are:
>    joeuser
> 
> however this doesn't allow the expected result - nobody can read the 
> volume, & joeuser can't write.
> 
> I have created 3 dummy PTS accounts (read, write, admin) to own the 
> various groups, this is just for neatness' sake.
> 
> OpenAFS is on OpenBSD 3.7 & windows, running 1.4 rc6, using
> ./configure --enable-transarc-paths --enable-fast-restart 
> --enable-bitmap-later --quiet --enable-debug --enable-bos-new-config 
> --enable-supergroups --enable-namei-fileserver --disable-kernel-module
> 
> -> windows client is 1.4 rc6
> -> openbsd clients are all arla from 3.7 release
> 
> 
> 4 questions:
> does anybody use supergroups?
	yes.   They've been in use at umich.edu since 1994.
> am I using them correctly?
	Looks ok.
> is there any other information I could collect that would help?
	tokens.
	result of using aklog/klog then checking permissions.
> are there any other docs other than the wiki for reference? google 
> doesn't return much.
	the source?
...

If "joeuser" can't write, that's interesting -- because that's not using
supergroups at all.  Presumably whatever problem you have here is most
likely something else.

Did you do a "klog" or "aklog" after you changed pts group membership?

The first time you connect to a fileserver, the fileserver does
a "getcps" to find out what groups you belong to.  After that,
the fileserver uses this cached list for all further permissions
checking.  That means if you are added to or removed from a pts group,
and you were already using a fileserver, that fileserver won't see
those pts group changes.

In order to make the pts group changes visible to the fileserver you
have to do something to cause a new connection to be made.  You can do
that by either (a) doing nothing and waiting a long time, for the
fileserver to time the connection out - when you touch the connection
again, the fileserver will renew the connection and get credentials
over again, or (b) using klog or aklog to associate new credentials
with your pag.  That will cause the cache manager to discard any
current connections for that pag and make new connections, which will
cause the right thing to happen on the fileserver.

			-Marcus Watts
			UM ITCS Umich Systems Group