David:
On Thu, 2009-07-23 at 04:58 -0500, Brian Cameron wrote:
Sun is already working to add DeviceKit support to Solaris
It would be good to the devkit-devel mailing list know about this.
Because if this is so, we need to change some of our plans; in
particular move the "make porting easier" up the priority list. Also, I
hope you guys know that PolicyKit is a not an optional dependency.
I have pinged the Sun team working on DeviceKit and suggested they
be better about communication with upstream by sending some status
to the devkit-devel mailing list.
Sun does not have much of
an interest in shipping modules which have a strong dependency on
PolicyKit
No-one ever explained to me why Sun is suddenly not interested in this -
and SUN did send patches to PolicyKit earlier on. The only explanations
I've seen (in private mails) included childish statements like claiming
PolicyKit is "rubbish" and that the author, me, didn't know what I was
doing.
Myself and Jim Li were the two Sun engineers working to make sure that
PolicyKit works on Solaris. Much of this work was done in late 2007 and
early 2008. At that time, there was not an urgent need for integrating
PolicyKit into Solaris, but we wanted to make sure that we were keeping
abreast with the new technologies that were going to have a lot of
impact on the desktop. We wanted to make sure we were more familiar
with the codebase and start getting fixes for Solaris-specific issues
upstream. We provided spec-files in the Solaris spec-files-extra
repository so that others in the OpenSolaris community could get
involved with building it if they wanted to further test it out.
If we gave the impression that we were being more aggressive about
integrating PolicyKit, that was not intended.
I can not speak for Sun in general on this matter, but my understanding
is that Sun does not have any problems with integrating a module like
PolicyKit. In fact, Solaris does already ship a stripped-down version
of PolicyKit that is only used by HAL. If you look at a recent
OpenSolaris release, you will see libpolkit.so in /usr/lib. However,
this is a hacked PolicyKit that just works as needed for HAL alone, and
does not provide any configuration for the user to change. Instead it
works with a RBAC backend.
Since PolicyKit relates so much to security, going through the processes
of review and auditing needed to integrate a more complete PolicyKit
will be cumbersome, though not impossible. The security team at Sun has
expressed some concerns about the maturity of PolicyKit, since it is
such a new framework. If some of these concerns were communicated in
childish ways in private emails, then I apologize.
Also, Solaris has a security rule that requires that users not be asked
to enter passwords for gaining authorization unless they are in the
trusted path. To my understanding, PolicyKit does not address this
issue today, perhaps because most Linux distros are not as strict about
this requirement. This technical issue could be overcome, for example,
by switching to a separate VT in the trusted path to display the
dialog.
There has been some concern expressed about using PolicyKit with an RBAC
backend. If Solaris ships configuration files for both RBAC and
PolicyKit, then users will likely need to understand and configure both
systems to properly configure their setup. There is a desire to avoid
adding unnecessary complexity. Perhaps a GUI that hides this complexity
from the user could help to address this concern.
Though, probably the main reason why there has not much of a drive to
add PolicyKit to Solaris is because there has not been much need. To
date, Sun has not had much of a problem integrating the GNOME stack
without having PolicyKit available. I am sure there are some features
that Solaris is lacking because of this, but I do not recall any bug
reports or user complaints about this. The lack of specific
need-to-have features that would be solved by adding PolicyKit makes
it easier to not integrate PolicyKit than to address all of the above
issues and concerns.
Anyway, maybe you should ask someone at Sun out the latest polkit
version
http://hal.freedesktop.org/docs/polkit/
which is a complete rewrite of the old code. PolicyKit, by itself, is
now merely an interface to interface to the authorization system -
adding support for a Solaris RBAC backend amounts to subclassing a
single class, implementing two methods and drop that code in an .so in
$libdir/polkit-1/extensions. Yes, you're welcome that it is now this
easy.
This does improve things a lot. As I mention above, HAL already uses
an old version of libpolkit with a hacked RBAC backend. At the very
least, it seems it would make sense to update to the new version of
PolicyKit to take advantage of the new, more flexible framework for
RBAC integratin. That is probably the practical next step towards
better integrating PolicyKit into Solaris.
I am not sure what the big deal is here. Nobody from Sun has been
complaining about GNOME being too Linux-ey, have they? Sun has always
had a good relationship with the GNOME community, and it has never been
particularly hard to get patches upstream to support things needed for
GNOME to work well on Solaris or OpenSolaris.
The perception, at least from me personally, is that Sun isn't doing a
very good job at *working* with the GNOME community. Case in point, if
RBAC or Visual Panels are oh-so-much-better, why the heck are you guys
not trying to push it for non-Linux?
Regarding RBAC, it has been a NIST standard since 1992. Sun is just one
company that implements RBAC, it is not a Sun technology. The fact that
PolicyKit has not well supported this standard is just one of the
current limitations of using PolicyKit.
http://csrc.nist.gov/groups/SNS/rbac/
Also, Jim and I did spend a fair bit of time working with you to make
it easier to support RBAC in PolicyKit. I suspect the new, more
flexible PolicyKit backend was implemented, in part, because of those
discussions we had. You make it sound like people from Sun have never
raised this issue before.
And actually do the integration
work inside GNOME instead of bolting your work on after the fact? That
would benefit both Sun, the rest of the GNOME community and it would
make you guys look a lot better. At least in my eyes.
I agree with you, Sun should be better about working with the GNOME
community.
That said, I am not sure that Visual Panels is a good fit for
non-Solaris systems. A main reason why Visual Panels was created was
because it has always been a huge amount of work to try and make
programs like the GNOME System Tools work well on Solaris. Making the
GNOME System Tools work with Solaris-specific features like ZFS, RBAC,
Zones, etc. is difficult. It is often hard to get such Solaris-specific
features upstream. The main advantage of Visual Panels is that it is
being engineered by a team which works very closely with the Sun kernel
team, and has been designed, from the ground up, to provide a good
system configuration system for Solaris-based systems.
That said, let me provide the following link to more information about
the project just in case there might be others in the GNOME community
with an interest in getting involved with Visual Panels.
http://opensolaris.org/os/project/vpanels/
Anyway, didn't mean to sound rude or too harsh, hope you guys will take
this as constructive criticism.
It is not too harsh. It is good to talk about.
Brian
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
