On 10/03/08 21:19, Nicolas Williams wrote: > Oh yes, I suppose that we don't need a file for this, provided that we > can name a profile (that users wouldn't necessarily have granted to > them) that lists the authorizations meant for pam_authorized to use. > > Either way, as long as the authorizations are not a module argument to > pam_authorized, I'll be happy.
So, how about we parse the arguments auths=, authsfile= and if they are absent we search for a profile with the name "pam_authorized.so.1" and consider the authorizations listed in it to be equivalent to being specified in auths=? (Is there a reserved name space in prof_attr/exec_attr? In auth_attr we've reserved solaris.* for system use, but no such equivalent seems to exist for prof_attr/exec_attr) In the current implementation that means that per-host policies are possible by specifying auths=/authsfile=, something needed until it becomes possible to specify hostnames or netgroup names in a prof_attr entry to specify its scope. The one question is how we should deal with substitutable values in authorization names -- should we just try to expand %h/%f/... in authorization names that we retrieved from prof_attr? Or is there some mechanism to ensure we don't try to expand something that's meant to be used as a literal? Bart
