Kevin Chadwick posted on Sun, 31 Mar 2013 20:39:00 +0100 as excerpted:
> Or they could build KDE without polkit, however I have read that KDE's
> position is that KDE built without polkit is unsupported and would like
> clarification on that if possible.
There's certainly parts of it that won't work (or even build) in that
case. All the pointy-clicky-priv-requiring stuff won't work, as it has
been "improved" to be more point-clicky and less passwordy, with polkit,
and the old way either won't work at all now, or will, but kde no longer
ships with a configuration that would do it. And parts of auto-mount and
the like will fail, due to missing components or bad permissions. Etc.
So (as a user) I'd guess that's the deal with support. The vision from
those involved in the various pieces is that they work point-clicky, in
many cases without requiring further authorization to do stuff that has
traditionally required such authorization, and if you choose not to do it
that way, in many cases you'd simply not be using the kde tools they've
designed to handle it, to handle it, so of course, that bit not being kde,
they won't support it.
> To me and please don't get offended. It basically comes down to a choice
> or perhaps laziness to use polkit over the even more capable and maximum
> security encouraging sudo which is compliant with Unixes traditionally
> modular nature and avoids these kind of dependency problems, which no
> one would argue is not a big problem and that people have been fighting
> against for years with varying success that seems to have fallen away of
> late.
... But it's not pointy-clicky enough. And actually asking for a
password to do something that could have system-wide effects isn't
considered easy enough any more.
> If you take PAM, support for it is widely available and has just been
> added to the Linux ssh port but dependency upon it in my experience is
> always optional.
Well, (open)ssh (I assume you mean openssh, not the original company-
produced version that went proprietary quite some years ago...) is a bit
of a special beast, as "upstream" for it is the BSD folks. They have
their own way of doing things, and their primary focus is the BSD side,
with the Linux port playing second fiddle. No big deal with it being
handled that way as there's certainly enough Linux-primary, BSD-second,
projects out there, and having the tables reversed once in awhile isn't
a /bad/ thing. But it does explain why the otherwise reasonably mature
ssh is only now getting PAM support on Linux.
Meanwhile, in general, PAM, pluggable authentication modules, was
designed with both pluggability and compatibility in mind, so there's
little surprise that it's optional.
Polkit is much different. It far more emphasizes dbus IPC and pointy-
clicky management, and as such, basically drops compatibility with the
old command line stuff by the wayside, since pointy-clicky's supposed to
be so much better.
> There are many who would not use PAM if you paid them
> too and I am sure RedHat would use nothing else and I am glad PAM's
> design does not cause people problems.
>
> I therefore suggest that polkit or KDE are designed incorrectly and
> would invite any thoughts or opinions on this.
I wouldn't say it's designed incorrectly, simply that the emphasis is
different than it used to be. If the emphasis is on automated policy and
single-signon management in a point-clicky world, polkit works well, and
that's where kde's (or at least that segment thereof that deals with
these things) focus seems to be, these days. If it's on giving the
sysadmin familiar with the old way more direct, troublefree and familiar
ways to text-config-file-edit the config, that's something entirely
different, and not where the people actually doing the kde coding are
taking it.
Of course, kde being a "volunteer" organization (if coders are getting
paid for it, it's their employers doing the volunteering), if your vision
is different and you're in a position to do so, volunteer your skills, or
money to sponsor someone else to do it, and I quite expect existing kde-
ers would be happy to either arrange for the components you produce to be
available alternatives, or to integrate the sudo-managed functionality in
parallel to the polkit managed functionality, probably with a kcontrol
applet to allow individual installations or users to choose one or the
other as appropriate.
However, it may well still remain a pre-compile-time choice, thus forcing
distros to choose one way or the other for their shipped binaries. And
actually, that's a pretty common solution -- far more common than I think
most binary-distro users (as opposed to package maintainers, who will
obviously need to know) realize.
That's actually one facet of the well known user/developer divide. FLOSS
was and remains designed for users that are both willing and able to take
part in creating their own software reality, and pre-supposes that at
minimum, they'll be a large enough share to keep the community self-
sustaining. But there's very much a divide between "simple users" and
"users who actively participate in choosing and building this software
reality", and simple users more or less get carried along on the tide of
those who actively participate. And the binary distros are, fortunately
or unfortunately, generally focused on these "simple users", who don't
care -- who in general don't WANT to care -- about the details. By
definition, these users in general just want it to work, and are happy
enough to let someone else make the decisions, as long as it does so.
Otherwise they'd be making other choices in regard to their distros,
choosing distros that gave them more power to make their own local
software reality, even if it meant a few extra hours doing a nearly
completely automated build in ordered to do so.
But that level of control isn't what most people want or are interested
in at all, as long as it works for them, and that's OK. Not everybody
has to want/need that level of control, and I'm glad there's distros out
there catering to the needs of the many, as well as those catering to the
needs of a rather smaller market segment, my own, where people want that
level of control and responsibility for themselves, even if they must pay
a (to them) relatively small cost in time and convenience terms in
ordered to be able to have it.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
