On 02 Oct 2008, at 21:21, Glenn Faden wrote:
> 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:
My idea here was to really allow a wildcard ("*"), permitting easy
specification of a whole group of authorizations in one go, for
example where you would have an auth structure like:
com.xyzcompany.systems.<hostname>.admin
com.xyzcompany.systems.<hostname>.secadmin
com.xyzcompany.systems.<hostname>.auditor
com.xyzcompany.systems.<hostname>.user
(presumably used by other tools on the system to determine specific
authorizations), as in such a case specifying
"auths=com.xyzcompany.systems.%h.*" would be sufficient to grant login
access to the system.
(The implementation could be done by calling getauthnam(3SECDB) to
iterate over "com.xyzcompany.systems.%h.*" and chkauthattr(3SECDB)
against each entry that returns)
> Embedded variables may be specified, and are expanded before making
> each authorization check.
>
> As you know, chkauthattr(3TSOL) check a single explicit
> authorization, and isn't particular efficient with respect to lookups.
>
> 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.
As the reverse domain name approach is the one we recommend in
auth_attr(4):
To avoid name conflicts, all other authorizations should use a prefix
that begins with the reverse?order
Internet domain name of the organization that creates the
authorization (for example,com.xyzcompany).
it seemed like the best approach.
The fact that we ship solaris.* auths that can't (unless someone
registers solaris as one of the new top-level domains) be a valid
reverse order DNS domain is thus indeed a good thing.
On 02 Oct 2008, at 23:46, Mike Gerdts wrote:
> On Thu, Oct 2, 2008 at 3:50 PM, Nicolas Williams
> <Nicolas.Williams at sun.com> wrote:
>> I like this very much, but I'd like the configuration for this module
>> not to have to be specified as a module argument -- that could get
>> unwieldy quick.
>
> Agreed. I'm envisioning a server that runs a J2EE instance (fronted
> by a SSO enabled web server) for many apps, and has NAS and database
> dependencies. In order to grant login privileges to all the people
> that may need to log in, those with any of the following
> authorizations would need to be allowed to log in for various reasons.
>
> com.mycompany.admin.solaris
> com.mycompany.admin.backups
> com.mycompany.admin.nas
> com.mycompany.admin.oracle
> com.mycompany.admin.weblogic
> com.mycompany.admin.iws
> com.mycompany.admin.sso
> com.mycompany.admin.app.salesguru
> com.mycompany.admin.app.partyplanner
> com.mycompany.admin.app.helloworld
I'm OK with having both auths= and authsfile=, though the above
example could be handled succinctly with a
"auths=com.mycompany.admin.*,com.mycompany.admin.app.*"
Bart
