[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