[OpenAFS-devel] pts examine

[Neulinger, Nathan]

Doesn't really matter in this case, unless you're concerned that someone
would want to grant admin access to "joe/admin" instead of granting
access to "joe" with instance "admin".

Since UserList only checks against the instance, the only problem would
be that if a "joe" with instance "admin" existed that you did NOT want
to grant access to. If that user didn't exist, it just wouldn't grant
any extra permissions. Someone going and creating "joe/admin" wouldn't
result in any security problem, since it would never compare against
"joe/admin" in the ticket.=20

Since we're slowly moving toward more real krb5 support, seems like we
need to pick one or the other to concentrate on, cause the more
krb5'ized it becomes, the more people are going to want to make use of
krb5 syntax.=20

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: Derrick J Brashear [mailto:shadow@dementia.org]=20
> Sent: Tuesday, December 03, 2002 1:15 PM
> To: openafs-devel@openafs.org
> Subject: RE: [OpenAFS-devel] pts examine
>=20
>=20
> On Tue, 3 Dec 2002, Neulinger, Nathan wrote:
>=20
> > You can remove those ifdef's, but as I said, I don't=20
> remember the discussion. I originally wrote those in there=20
> cause I wanted to do just what you are doing locally. The=20
> code was committed, but the krb5 syntax support was disabled=20
> in the commit.
> >
> > I do not believe there would be any problem with enabling=20
> it, but others may have something to say here.
>=20
> See my earlier comment: "/" is a legal character in krb4 and=20
> so while you
> might be smart enough to not allow a user named "foo/admin"=20
> to be created
> it's legal to do so; We never figured out how we were going=20
> to deal with
> this scenario, and encouraging people to do something which=20
> might end up
> conflicting with whatever we end up needing to do later seems unwise.
>=20
>=20
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>=20