[OpenAFS] adding a group to a group?
Dexter Kimball
dhk@ccre.com
Tue, 8 Mar 2005 07:06:04 -0700
Oops.
Omit the comment about "no current support for groups within groups" for
OpenAFS. Had my Transarc hat on. There is a compile-time argument for
supergroups for OpenAFS. My bad. (My bad memory :)
I'm not entirely sure why you want a group that contains all users and =
all
IP groups, unless the distinction between "all users in this PT group" =
and
"all users authenticated in my cell" is somehow critical to you -- which
does happen if there are some users in your cell who do have accounts =
but
who must be restricted from the "MyCell/system:authuser" groups. If =
not,
why maintain a "all users in my cell" group? Perhaps I missed something
earlier in the thread.
Kim
> -----Original Message-----
> From: openafs-info-admin@openafs.org=20
> [mailto:openafs-info-admin@openafs.org] On Behalf Of Dexter Kimball
> Sent: Tuesday, March 08, 2005 6:51 AM
> To: 'Lars Schimmer'
> Cc: openafs-info@openafs.org
> Subject: RE: [OpenAFS] adding a group to a group?
>=20
>=20
> IP ACLs are not what most folks expect.
>=20
> 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
>=20
> 2. Unlike other user entries, these entries have no effect if=20
> placed on an
> ACL directly. (Unlike other AFS users, "IP users" don't ever=20
> have a token.)
>=20
> 3. Add the "IP user" to a group. Let's use "MyIPgroup"
>=20
> 4. Place "MyIPgroup" on the ACL of choice with whatever=20
> permissions you
> like.
>=20
> 5. "CPS" stands for "Current Protection Subdomain," according=20
> to the old AFS
> programming references.
>=20
>=20
> 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=20
> specific group
> or of all the groups a specific user belongs to.=20
>=20
> Instead, upon identifying a user (via the token, so this=20
> isn't true of "IP
> users") the fileserver requests the current protection=20
> information for that
> user from the PT Server: "Hey, ptserver, what groups does=20
> user "X" belong
> to?"
>=20
> Since the fileserver doesn't directly track changes to the=20
> PTS database,
> there's a worry that perhaps user X will be added to or=20
> removed from groups
> -- so the fileserver needs to refresh the user's protection=20
> information from
> time to time.
>=20
> For any given user, X, (except "IP users") there are two ways=20
> the fileserver
> is triggered to refresh the Current Protection Subdomain (CPS): =20
>=20
> A) The token presented to the fileserver for user X is not=20
> 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=20
> token. When the
> fileserver sees the new token version number for user X, the token
> re-requests information from the PT server.=20
>=20
> B) The CPS timeout is reached for the user.
>=20
> For an "IP user" trigger A cannot be used -- the "IP user"=20
> doesn't have a
> token to present to the fileserver.
> For an "IP user" trigger B is the only trigger -- so if the=20
> "IP group" is
> modified you have to wait until the CPS timeout occurs, and then the
> fileserver will start seeing the new membership.
>=20
> getcps() IIRC says "for user X or group Y, has the CPS=20
> timeout been reached?
> should I RPC the PT server again?"
>=20
>=20
> CPS "TUNING"
>=20
> The CPS timeout can be changed via the command-line=20
> /usr/afs/bin/fileserver
> startup parameters in your startup scripts.
>=20
> Specifically the switch
> [-hr <number of hours between refreshing the host cps>]
> is used. Try "/usr/afs/bin/fileserver -help" to see other options.
>=20
> In Transarc AFS (and I believe in OpenAFS) the default CPS=20
> timeout is two
> hours. You can set it to one hour via the -hr switch. NB=20
> that the -hr
> switch specifies one-hour increments. I don't know what=20
> happens if "0" is
> specified.
>=20
> =3D=3D=3D=3D ACLS, "IP groups" and "system:authuser" =3D=3D=3D
>=20
> Given a cell "MyCell" and a user "MyUser", MyUser is a member of
> system:authuser iff MyUser has a valid token for MyCell. =20
> That is, the scope
> of "system:authuser" is "one specific cell -- the cell that=20
> the fileserver
> belongs to, as defined in the fileserver's /usr/afs/etc/ThisCell file.
> Tokens from any other cell do not qualify.
>=20
> "IP groups" do not qualify for system:authuser -- since an=20
> "IP user" doesn't
> present a token to the fileserver at all.
>=20
> However, a member of the "IP group" is assigned permissions=20
> on an ACL and
> does not need a token and does not need to be a member of=20
> system:authuser
> per se or of any other PT group: placing the "IP group" on an ACL is
> sufficient.
>=20
> YOUR QUESTION
>=20
> If I understand correctly, you wish parts of your tree to be=20
> world readable
> but not other parts.
>=20
> You want a single group that includes all users and all IP=20
> groups, and then
> propose to put that single group on ACLs all over the cell.
>=20
> Since groups containing other groups aren't yet supported,=20
> you'll need two
> entries instead of one, but the two entries will give you=20
> what you want as
> long as you eliminate system:anyuser where appropriate:
>=20
> system:authuser <perms>
> MyIPgroup <perms>
>=20
> These two entries say "only users who have valid tokens in my=20
> cell" and "any
> requests, authenticated or no, from this group of IPs or=20
> wildcarded subnets"
>=20
> OTHER POINTS OF INTEREST
>=20
> Since a user can "fs mkmount" a volume anywhere she/he has=20
> write permission,
> it is not sufficient to break system:anyuser access high in=20
> the volume chain
> and quit. system:anyuser access must be broken at the root=20
> node of each
> volume to be shielded from anonymous access. That is, mount=20
> the volume at
> /a/b/c and then "fs setacl /a/b/c system:anyuser none" for=20
> every target
> volume.
>=20
>=20
>=20
> =
=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
>=20
>=20
>=20
>=20
>=20
>=20
> > -----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=20
> 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=20
> 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=20
> 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=20
> 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
>=20
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>=20