Gary Winiger wrote:
>>> That depends on the scope of the umbrella requested. This
>>> seems limited to the interaction between HAL PM support
>>> and the LSARC GPM case.
>>
>>Yes, this addresses specific issues that are clearly defined for HAL/GPM
>>and which I believe will give sufficient information to move these
>>cases forward.
>
>
> After agreement on Randy's posting, but not from your's.
>
>
>>>>GPM Defaults
>>>
>>>
>>>>For any user who is logged into an X session, GPM will by default
>>>>have these actions:
>>>
>>>
>>> How does this user get permission to do these actions?
>>
>>The user will get permission by having the correct RBAC authorization
>>as described in this case.
>
>
> So a user's defaults are ignored at login if the user doesn't
> have appropriate authorization? How does the user figure this
> out? And how does the user get appropriate authorization?
> Where are the administative steps defined/documented. I.e.,
> what's the user and administrator experience? (Bob Hagmann
> memorial question)
The only users allowed to use GPM are root and console owner which will
be the Workstation Owner. On initial install, all console owners and
root will have permission. The only reason a console owner will not
have permission is if the administrator removes their authorization.
The plan would be to document the administrative steps for power mgmt
RBAC in the admin guide or what's new guide.
>
>
>>> What happens if the user doesn't have permission?
>>>
>>
>>The GPM GUI will not show options that are not authorized for the user.
>
>
> That's fine for showing what can be changed, but doesn't do
> much for setting the user's defaults. Viz a shared home directory.
>
>
>>>>If no one is logged into an X session, the defaults above will be true
>>>>except for the following:
>>>
>>>
>>> In some sense, how/when is this done? Upon initial system boot
>>> and at every logout? Is there a notification architecture for
>>> user logout?
>>
>>Yes, these defaults are set upon initial system boot and at every
>>logout. There is no existing notification architecture for logout.
>>A sysevent will need to be generated at console logout.
>
>
> Please say more about recognizing console logout. Is this
> project defining a new sysevent? What's the architecture
> for sending that event?
A new sysevent would be generated in dtlogin and gdm at the time of
console logout. Implementation-wise, the sysevent could be generated
near or inside di_devperm_logout() in dtlogin, but I don't think gdm
uses this call.
>
>
>>>>Lid - When a user closes the lid, the system will by default suspend if
>>>>supported. If suspend is not supported, the action will be to do nothing
>>>>by default. One can change the default to do nothing.
>>>
>>>
>>> Who is the "One"? How does the "One" change things?
>>> Are these system wide defaults? Are there new /etc files?
>>> Are the defaults part of an SMF service? What service? ...
>>
>>When no one is logged in, "One" means root. A root user would have to
>>log in and use the GPM GUI to change the defaults.
>>
>>GConf has a system wide repository in /etc/gconf. The GPM system wide
>>defaults are stored here. The GPM defaults for any user are stored in
>>$HOME/.gconf. AFAIK, there is no SMF service associated with GConf, but
>>is managed by the /usr/lib/gconfd-2 daemon.
>
>
> So your saying only root can administer /etc/gconf GPM defaults?
> Why should that be so? Why shouldn't a properly authorized
> user/role be able to modify the system defaults?
GPM uses GConf which only allows the database owner to change the files.
Also, I don't see why GPM policy couldn't require only root to modify
root files.
>
> Perhaps I'm getting into the LSARC case, but these are really
> Siamese twins that need an overarching architecture before they
> can be separated. Perhaps this calls into the entire GNOME
> administrative architecture. I'm not suggesting this project
> is responsible for that architecture, but does point out the
> that I don't know where to find it to ensure it meets the various
> Solaris Policies.
>
>
>>>>Auditing
>
>
>>> What I was asking the team about was the architecture that was
>>> relevant to audit across a system discontinutity. It's neither
>>> self evident from this case, or uadmin(1M), or uadmin(2).
>>> I've also filed a man page bug 6664263 uadmin(2) is incomplete
>>>
>>> Reading over 1992/201, 1992/202, 1993/243, 1993/319, 1993/462,
>>> 1996/058, 1996/257, 1997/126, 1997/326, 2005/067 haven't filled
>>> in the gaps.
>>>
>>> Is there a suggestion where else to gleen the architecture?
>
>
> Any thoughts??
I was leaving this question for the power mgmt team as part of the
resolution on the bugs you filed. I don't have much insight on this
issue (I'm not part of the power mgmt team).
>
>
>>>>Security
>>>
>>>
>>>>PolicyKit is a security policy on Linux similar to RBAC. The plan has
>>>>been to port the pieces that are needed into RBAC. libpolkit is a
>>>>small piece of PolicyKit that has been ported to use RBAC since its
>>>>introduction in PSARC/2005/399 Tamarack: Removable Media Enhancements. So
>>>>far, projects will only port the piece of PolicyKit that is needed. What
>>>>about the rest of PolicyKit? Any piece of PolicyKit used by a project team
>>>>would be required to port to RBAC and thus keep with the requirement
>>>>of having only one security policy and administration.
>>>
>>>
>>> I remain concerned with a piece meal approach without an umbrella
>>> to describe how/where the pieces fit together.
>>
>>A PolicyKit umbrella is not trivial and it would be a surprise
>>requirement due to the precedent case.
>
>
> I don't follow what you're saying. I read you comment as saying
> this project (and hinting others) well be taking parts of PolicyKit
> into Solaris. Without some review if PolicyKit how can the
> architecure of the parts be viewed as correct?
The port for libpolkit does the following in pseudo code:
if (hal-power-shutdown) {
authname = "solaris.system.shutdown";
}
chkauthattr(authname);
where hal-power-shutdown is the Linux privilege. Yes, this can be
called a port, but it should not be considered PolicyKit. My statement
is a generalization for projects, but you can see what HAL does
right now really doesn't depend on PolicyKit.
>
>
>>These new HAL and GPM cases do not actually rely on PolicyKit so there
>>is no need for an umbrella from these case. libpolkit maps Linux
>>privileges to RBAC and even this can be removed since it will be easy to
>>use the correct RBAC authorization without needing an explicit mapping.
>
>
> If you remove libpolkit what are the side consequences?
> I'm not suggesting it be removed, just a lack of knowing
> where the ARC case that reviewed it.
The libpolkit interface would need to be replaced since some programs
depend on it from gnome and HAL. libpolkit was approved in the
PSARC/2005/399 Tamarack case which I thought you were the PSARC sponsor?
Phi
