[OpenAFS] adding a group to a group?

Dexter Kimball dhk@ccre.com
Tue, 8 Mar 2005 06:51:05 -0700


IP ACLs are not what most folks expect.

1.  Create a user whose name is <IP> using "0" as a wild card, IIRC.
     192.168.1.5
     192.168.1.0
     192.168.0.0

2. Unlike other user entries, these entries have no effect if placed on =
an
ACL directly.  (Unlike other AFS users, "IP users" don't ever have a =
token.)

3. Add the "IP user" to a group.  Let's use "MyIPgroup"

4. Place "MyIPgroup" on the ACL of choice with whatever permissions you
like.

5. "CPS" stands for "Current Protection Subdomain," according to the old =
AFS
programming references.


CPS: =20
The fileserver doesn't bother to keep track of all changes to the PTS
database, so doesn't have a complete picture of members of a specific =
group
or of all the groups a specific user belongs to.=20

Instead, upon identifying a user (via the token, so this isn't true of =
"IP
users") the fileserver requests the current protection information for =
that
user from the PT Server:  "Hey, ptserver, what groups does user "X" =
belong
to?"

Since the fileserver doesn't directly track changes to the PTS database,
there's a worry that perhaps user X will be added to or removed from =
groups
-- so the fileserver needs to refresh the user's protection information =
from
time to time.

For any given user, X, (except "IP users") there are two ways the =
fileserver
is triggered to refresh the Current Protection Subdomain (CPS): =20

A) The token presented to the fileserver for user X is not the same =
version
number -- that is, the user issues "klog" and refreshes his/her token
causing a new token version number to be generated for the token.  When =
the
fileserver sees the new token version number for user X, the token
re-requests information from the PT server.=20

B) The CPS timeout is reached for the user.

For an "IP user" trigger A cannot be used -- the "IP user" doesn't have =
a
token to present to the fileserver.
For an "IP user" trigger B is the only trigger -- so if the "IP group" =
is
modified you have to wait until the CPS timeout occurs, and then the
fileserver will start seeing the new membership.

getcps() IIRC says "for user X or group Y, has the CPS timeout been =
reached?
should I RPC the PT server again?"


CPS "TUNING"

The CPS timeout can be changed via  the command-line =
/usr/afs/bin/fileserver
startup parameters in your startup scripts.

Specifically the switch
     [-hr <number of hours between refreshing the host cps>]
is used.  Try "/usr/afs/bin/fileserver -help" to see other options.

In Transarc AFS (and I believe in OpenAFS) the default CPS timeout is =
two
hours.  You can set it to one hour via the -hr switch.  NB that the -hr
switch specifies one-hour increments.  I don't know what happens if "0" =
is
specified.

=3D=3D=3D=3D ACLS, "IP groups" and "system:authuser" =3D=3D=3D

Given a cell "MyCell" and a user "MyUser", MyUser is a member of
system:authuser iff MyUser has a valid token for MyCell.  That is, the =
scope
of "system:authuser" is "one specific cell -- the cell that the =
fileserver
belongs to, as defined in the fileserver's /usr/afs/etc/ThisCell file.
Tokens from any other cell do not qualify.

"IP groups" do not qualify for system:authuser -- since an "IP user" =
doesn't
present a token to the fileserver at all.

However, a member of the "IP group" is assigned permissions on an ACL =
and
does not need a token and does not need to be a member of =
system:authuser
per se or of any other PT group: placing the "IP group" on an ACL is
sufficient.

YOUR QUESTION

If I understand correctly, you wish parts of your tree to be world =
readable
but not other parts.

You want a single group that includes all users and all IP groups, and =
then
propose to put that single group on ACLs all over the cell.

Since groups containing other groups aren't yet supported, you'll need =
two
entries instead of one, but the two entries will give you what you want =
as
long as you eliminate system:anyuser where appropriate:

system:authuser <perms>
MyIPgroup  <perms>

These two entries say "only users who have valid tokens in my cell" and =
"any
requests, authenticated or no, from this group of IPs or wildcarded =
subnets"

OTHER POINTS OF INTEREST

Since a user can "fs mkmount" a volume anywhere she/he has write =
permission,
it is not sufficient to break system:anyuser access high in the volume =
chain
and quit.  system:anyuser access must be broken at the root node of each
volume to be shielded from anonymous access.  That is, mount the volume =
at
/a/b/c and then "fs setacl /a/b/c system:anyuser none" for every target
volume.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
Kim (Dexter) Kimball
CCRE, Inc.
dhk<at>ccre.com






> -----Original Message-----
> From: openafs-info-admin@openafs.org=20
> [mailto:openafs-info-admin@openafs.org] On Behalf Of Lars Schimmer
> Sent: Monday, March 07, 2005 2:13 PM
> Cc: openafs-info@openafs.org
> Subject: Re: [OpenAFS] adding a group to a group?
>=20
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Derek Atkins schrieb:
> | Lars Schimmer <schimmer@cg.cs.tu-bs.de> writes:
> |
> |
> |>That=B4s exact not what I search :-)
> |>I want to open our cell at the firewall to be accessed from=20
> all over the
> |>world. But I don=B4t want every other AFS user to read our=20
> data, so I need
> |>a group called "all" to inherit our PCs and all our users=20
> (which are all
> |>members in some groups).
> |
> |
> | Uhh, the system:authuser group contains implicitly every=20
> user in your
> | cell, but not anyone else.  That would seem to solve some of your
> | issues.  I'm not sure exactly what you mean by "inherit our PCs".
> | Do you wish to grant access to PCs on the local network without
> | requiring user authentication?
>=20
> Oh, kinda misunderstanding on my site. I thought system:authuser would
> be EVERY user who has got a token, equal if my cell or from=20
> another cell.
> And yes, the PCs with their IPs in one group and the users with their
> groups. PCs with their IP is no problem, although I read that it=B4s
> better to include them in a group rather than set the IP=20
> direct in the ACL.
> BTW, in a mail few days ago, I got a answer like:
> "5. wait until the getcps interval has passed. no tokens involved,, so
> you have to wait until the previous getcps times out"
> So I watched out openafs.org but haven=B4t found in the docs=20
> something to
> explain this. When does "getcps" time out and is there a way to manual
> control the getcps interval?
>=20
>=20
> | -derek
>=20
> Thx so far
> Lars
> - --
> - -----------------------------------------------------------------
> Technische Universit=E4t Braunschweig, Institut f=FCr Computergraphik
> Tel.: +49 531 391-2109            E-Mail: schimmer@cg.cs.tu-bs.de
> PGP-Key-ID: 0xB87A0E03
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
>=20
> iD8DBQFCLMPTVguzrLh6DgMRAl3hAJ4xuvedNSbrEOX/miLXKa9HQzNSigCgxsH9
> XY0bBIUl2rzFJzd+mdgV8AE=3D
> =3DZsPD
> -----END PGP SIGNATURE-----
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>=20