> > >
> > >>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?
The "users's defaults" will also be ignored if the underlying
feature doesn't exist or isn't supported on the particular platform.
In fact, as the discussion in this case seems to be primarily directed
towards the suspend/resume feature, it should be noted that closing
the lid on a laptop running Solaris will currently result in nothing
happening (except a screen blank) as today, there is not a laptop that
is supported for suspend and resume. And even if there were, there is
no guarantee that the machine would actually suspend if asked due to
the myriad of non-PM code that can cause a suspend to fail.
It is also possible that "defaults" could be different on various
platforms (authorizations and/or PM actions), or maybe defined by a
systems adminstrator. So there are plenty of proper methods by which
a user would get "defaults" that are "different" than expected. But
these are all policy decisions, the arcitecture is to provide a way to
have and implement policies.
> 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)
Authorizations come from RBAC, so they would use those defined and
documented steps and tools, and have that user and administrator
experience.
>
> > > 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.
We can rathole on the authorization (and audit) questions for a long
time. But are the questions and answers really different than any
other case, or maybe are they really implementation details?
>
> > >>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?
>
Phi can (and should) answer better, but I believe this intent was to
provide a mechanism for some action when there is no user logged in.
And my understanding was to describe that there may need to be some
work to have HAL be notified of the event that a GNOME user has logged
out, not that a new Solaris notification needs be added.
> > >>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?
>
> 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.
Yes, this is more in line with the LSARC case, as this is the
primary UI. But even there, "defaults" are a policy decision, and not
really architecture.
Not wanting to polute this case any more than necessary, but IMHO
these particular defaults should be defined to *NOT* suspend on a lid
close, as at this time I don't want any user to believe that his
machine will definitely suspend if they close the lid, but instead
require that they actually hit a "Suspend" button and physically
verify that the machine suspended before closing the lid. At some
time in the future, when there are more compliant drivers, code that
prevents suspend is cleaned up, and the majority of platforms _will_
suspend, we can change the default.
>
> > >>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
uadmin(1M)/uadmin(2) is out of the scope of this case, as this case
only involks these Solaris commands/tools that cause the discontinuity,
and the brokeness (which, incidentally, has been there for *many*
years) is in these utilities.
> > >
> > > 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??
None of the above cases will be usefull in understanding GNOME Power
Manager or HAL, as (IIRC) they are all core power management cases
(initial suspend/resume, some configuration follow-on, CPUPM, etc.),
none of which are referenced in the initial case, nor are they
relevant to any extent outside of any committed API's they define that
might be consumed by HAL. Any questions/issues with uadmin should be
taken offline (and probably with x86power-iteam at sun.com).
The Tamarack, D-BUS, Battery and CPFreq cases will provide a better
understanding to HAL, and all have diagrams that show how GNOME
utilities (including GPM) interface to HAL and to Solaris (I think
even the GPM case has a diagram of the GNOME/HAL/Solaris
relationship).
These cases are:
PSARC/2005/399 Tamarack: Removable Media Enhancements in Solaris
PSARC/2007/679 CPUFreq HAL
PSARC/2006/601 Battery Project
LSARC/2006/368 D-BUS Message Bus System
LSARC/2007/702 Gnome Power Manager
>
> > >>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?
I think there is definitely a hint that there needs to be a better
understanding of the impending PolicyKit/RBAC collision. I also
believe that this investigation is best undertaken proactively by
the security group, as they are far more the experts in RBAC *and*
security, and are better suited to understand how to manage the
collision. This case is *only* adding a few more translations to
those previously defined in Tamarack (and maybe CPUFreq).
>
> > 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.
I believe that this was suggested, as libpolkit and other security
concerns (and not power management, I might add) have dominated the
discussion, and there was at least one person who suggested that
removing it would terminate the contention. IMO, at best this would
only move the contention, and delay the inevitable (sooner or later
Solaris Security will need to address PolicyKit issues).
---- Randy
>
> Gary..
>
