Glenn Faden wrote: > Darren and Bart, > > I like this idea. I have a few comments about the authorization > specification. The man page states: > > The argument to auths is a comma-separated list of authorization names > chosen from those names defined in the auth_attr(4) database. Wildcards > may be specified. Any one authorization listed is sufficient to be > granted access. > > The term "wildcard" has previously referred to the * that matches any > corresponding components after the dot.
> However, here the term seems to > apply to substitutions resulting from expanded variables. Since I assume > that * is not allowed, some better term like: > > Embedded variables may be specified, and are expanded before making each > authorization check. Okay we can clarify that so there is no confusion. > As you know, chkauthattr(3TSOL) check a single explicit authorization, > and isn't particular efficient with respect to lookups. Yes we do, but it is the only interface we have. At least this will only happen at login time. > It is ironic that your proposal supports reverse order names. The > original proposal I submitted to PSARC has all of the Solaris > authorizations start with com.sun, but we were forced to use solaris, > instead. I guess that is a good thing now, since none of our existing > authorizations will match a hostname on SWAN. > > Does the reverse ordered authorization require a hostname match, or can > it just match a domain? If you use %f or %F then the hostname must be included. If you use %d or %D then it is just the DNS domain name (forward or reverse). > This last feature doesn't appear to scale very well. I don't understand why that wouldn't scale well ? -- Darren J Moffat
