PolicyKit authentication agent changes

[Matthias Clasen]

As of version 0.100 (which will land in F15 as a post-alpha update), the
polkit-gnome package will no longer install an autostart file for
polkit-gnome-authentication-agent-1. Instead, each desktop environment
is reponsible for making sure that an authentication agent is running.

For GNOME, this is done by gnome-session installing an autostart file
with OnlyShowIn=GNOME;. Other desktop environments that rely on
polkit-gnome need to do something similar.

_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

[Christoph Wickert]

Am Mittwoch, den 23.02.2011, 15:55 -0500 schrieb Matthias Clasen:
>  As of version 0.100 (which will land in F15 as a post-alpha update),
> the
>  polkit-gnome package will no longer install an autostart file for
>  polkit-gnome-authentication-agent-1. Instead, each desktop environment
>  is reponsible for making sure that an authentication agent is running.
>  
>  For GNOME, this is done by gnome-session installing an autostart file
>  with OnlyShowIn=GNOME;. Other desktop environments that rely on
>  polkit-gnome need to do something similar. 
Adding "OnlyShowIn" is certainly a step in the right direction but I'm
afraid it will break many desktops out there, namely all window manager
such as openbox, fluxbox, icewm etc. Adding a desktop file there doesn't
make much sense as these WMs don't "rely" on an authentication agent.
It's the applications that rely on it, but we don't have control over
what software people install.

I made a different proposal last year, please refer to 
http://lists.fedoraproject.org/pipermail/devel/2010-April/134578.html

IMHO my approach has the advantage that it works for all DEs/WMs:
Install a program that needs an authentication agent, it will pull in
one of them through the virtual provides and the agent will be started
on the next time you log in.

We achieve this by making one agent the default. The default agent will
have "NotShowIn=" to exclude the DEs that have an agent of their own
while the others will have "OnlyShowIn=" to limit them to their desktop.

I don't care which one is default is as long as it has only a small
dependency footprint (kdebase-runtime for example has not). I only
suggested lypolkit because it will be chosen by yum in most situations
anyway.

Can you explain what the advantage of your approach is? From a packaging
point it looks broken: One the one hand we package a authentication
agent that cannot run by itself, on the other we package an autostart
file for something that is not necessarily installed.

Regards,
Christoph

[Matthias Clasen]

On Thu, 2011-02-24 at 00:14 +0100, Christoph Wickert wrote:

>  Can you explain what the advantage of your approach is? From a
> packaging
>  point it looks broken: One the one hand we package a authentication
>  agent that cannot run by itself, on the other we package an autostart
>  file for something that is not necessarily installed. 
Not sure what you mean with 'not installed'.
gnome-session requires polkit-gnome, so it better be installed.

Not sure what you mean by 'cannot run by itself' either. The
authentication agent in polkit-gnome is perfectly capable of running all
by itself. The package just doesn't inject itself in random desktop
environments anymore by installing an autostart file.

I don't mind if you add a provides to your polkit agent implementation
that wms can depend on. Thats between you and the window managers... but
as far as gnome is concerned, we don't want to depend on anything
virtual, but control which agent is running.

[Christoph Wickert]

Hi Matthias,

thanks for your quick response. I was busy, that's why I'm not so quick.

Am Mittwoch, den 23.02.2011, 20:08 -0500 schrieb Matthias Clasen: 
>  On Thu, 2011-02-24 at 00:14 +0100, Christoph Wickert wrote:
>  
>  > Can you explain what the advantage of your approach is? From a packaging
>  > point it looks broken: One the one hand we package a authentication
>  > agent that cannot run by itself, on the other we package an autostart
>  > file for something that is not necessarily installed.
>  
>  Not sure what you mean with 'not installed'.
>  gnome-session requires polkit-gnome, so it better be installed. 
Thanks for the pointer, you didn't mention that in your mail. 

>  Not sure what you mean by 'cannot run by itself' either. The
>  authentication agent in polkit-gnome is perfectly capable of running all
>  by itself. The package just doesn't inject itself in random desktop
>  environments anymore by installing an autostart file. 
It cannot run because it is not started. It is not about random desktops
but about a defined list of desktops. We need all maintainers of a DE
work together on this list, therefor I made my proposal one year ago.

>  I don't mind if you add a provides to your polkit agent
> implementation
>  that wms can depend on.  
There is nothing to add, the virtual provides
"PolicyKit-authentication-agent" is already in place for all packages.

>  Thats between you and the window managers... but
>  as far as gnome is concerned, we don't want to depend on anything
>  virtual, but control which agent is running. 
I can understand this very well, but I never said the DE should depend
on the virtual provides, the applications should. A DE should depend on
the agent of the desktop, the apps should depend on a generic agent and
use the virtual provides.

Imagine you install gnome-packagekit in Xfce: It will pull in say
polkit-gnome but still not work.

Summing it all up: I still don't see the benefit of the new packaging.
polkit-gnome-authentication-agent-1 doesn't start on any 'random'
desktop. Indeed this is a step in the right direction and I appreciate
it because I'm on the receiving side of bugs [1].

But wether or not polkit-gnome-authentication-agent-1 starts on any
'random' desktop has nothing to do with your new packaging but with the
fact that you have switched from "NotShoIn" to "OnlyShowIn". The
exactly
same effect could be achieved without changing the packaging, so there
is no benefit, but on the other hand it breaks many DEs / WMs that you
might not care about.

Regards,
Christoph


[1] https://bugzilla.redhat.com/show_bug.cgi?id=657006

[Kevin Kofler]

Christoph Wickert wrote:

>  Am Mittwoch, den 23.02.2011, 20:08 -0500 schrieb Matthias Clasen:
> > Thats between you and the window managers... but
> > as far as gnome is concerned, we don't want to depend on anything
> > virtual, but control which agent is running.
>  
>  I can understand this very well, but I never said the DE should depend
>  on the virtual provides, the applications should. A DE should depend on
>  the agent of the desktop, the apps should depend on a generic agent and
>  use the virtual provides. 
Well, having the apps depend on the virtual Provides is only of limited use 
because what yum picks if you're lacking an agent is not necessary the 
correct agent for your desktop. The app cannot really know what agent is the 
correct one, so there's no good way to put the dependency in the app. (We 
can only have the app depend on "any PolicyKit authentication agent", which 
is what the virtual Provides does, but this still doesn't ensure that the 
correct one for your desktop is present.)

Therefore, the dependency really needs to be carried by the desktop 
environment, at which point there's no point in having the apps Require 
anything at all. IMHO, PolicyKit authentication should just be considered a 
basic desktop service which is present in ANY GUI desktop, it's up to the 
desktop environment to Require the proper agent (and up to there, I 
definitely agree with Matthias). In fact, kdebase-workspace already 
Requires: polkit-kde.

Once we're there, Matthias is saying that we can just as well have the 
desktop also START the authentication agent. I'm not entirely sure that this 
is the best approach, but at that point, this isn't really THAT important. 
You have to put in a Requires for the authentication agent anyway, so at 
that point you can just as well drop in an autostart file, too. (And in 
fact, don't some of the desktops/WMs you have in mind require their own non-
XDG autostart setup anyway?)

>  Imagine you install gnome-packagekit in Xfce: It will pull in say
>  polkit-gnome but still not work. 
That's exactly why it's not the app's job to pull in an authentication 
agent. (Any application (as opposed to desktop environment / workspace) 
package with an explicit Requires on a specific agent is broken and needs to 
be fixed.)

>  Summing it all up: I still don't see the benefit of the new
> packaging.
>  polkit-gnome-authentication-agent-1 doesn't start on any 'random'
>  desktop. Indeed this is a step in the right direction and I appreciate
>  it because I'm on the receiving side of bugs [1].
>  
>  But wether or not polkit-gnome-authentication-agent-1 starts on any
>  'random' desktop has nothing to do with your new packaging but with the
>  fact that you have switched from "NotShoIn" to "OnlyShowIn". The
> exactly
>  same effect could be achieved without changing the packaging, so there
>  is no benefit, but on the other hand it breaks many DEs / WMs that you
>  might not care about. 
The OnlyShowIn change would be breaking "random other WMs" anyway, if they 
expected polkit-gnome to run. And if not, why do you care where the 
autostart file sits? If it's OnlyShowIn=GNOME;, it'll have no effect for you 
anyway.

        Kevin Kofler

[Christoph Wickert]

Am Samstag, den 26.02.2011, 11:58 +0100 schrieb Kevin Kofler:
>  Christoph Wickert wrote:
>  
>  > Am Mittwoch, den 23.02.2011, 20:08 -0500 schrieb Matthias Clasen:
>  >> Thats between you and the window managers... but
>  >> as far as gnome is concerned, we don't want to depend on anything
>  >> virtual, but control which agent is running.
>  > 
>  > I can understand this very well, but I never said the DE should depend
>  > on the virtual provides, the applications should. A DE should depend on
>  > the agent of the desktop, the apps should depend on a generic agent and
>  > use the virtual provides.
>  
>  Well, having the apps depend on the virtual Provides is only of limited use 
>  because what yum picks if you're lacking an agent is not necessary the 
>  correct agent for your desktop. 
yum should pick the correct agent in most cases because it has a
provider to only install as little packages as necessary. If you have
GTK+ apps installed it wont install polkit-kde because of the whole QT /
KDE dependencies.

>  The app cannot really know what agent is the 
>  correct one, so there's no good way to put the dependency in the app. (We 
>  can only have the app depend on "any PolicyKit authentication agent", which 
>  is what the virtual Provides does, but this still doesn't ensure that the 
>  correct one for your desktop is present.)
>  
>  Therefore, the dependency really needs to be carried by the desktop 
>  environment, 
I fully agree to what you wrote and I never said something different. A
desktop can depend on an agent - given that if it includes one.

>   at which point there's no point in having the apps Require 
>  anything at all.  
Please try to look beyond the rim of your KDE teacup for a moment. What
about the DEs / WMs that do not provide a polkit agent? Shouldn't we
make things like virt-manager just work in *every* environment?

>  IMHO, PolicyKit authentication should just be considered a 
>  basic desktop service which is present in ANY GUI desktop, it's up to the 
>  desktop environment to Require the proper agent (and up to there, I 
>  definitely agree with Matthias). In fact, kdebase-workspace already 
>  Requires: polkit-kde. 
Again you are arguing from the POV of a full featured DE. Take Xfce for
example: It is a very complete environment but still lacks a polkit
agent.

We could even go one step further and question your approach: I need to
use some KDE applications and due to the monolithic packaging I also
need to install kdebase-workspace. But I never start KDE, so why am I
forced to install a second polkit agent then? I have to admit that I
don't know the answer to this question and requiring polkit-kde looks
like the best solution because my situation is a corner case.

>  Once we're there, Matthias is saying that we can just as well
> have the 
>  desktop also START the authentication agent. I'm not entirely sure that this 
>  is the best approach, but at that point, this isn't really THAT important.  
It is because it breaks other desktops.

>  You have to put in a Requires for the authentication agent anyway, 
s/the/an. 'The' agent can only be used if there is one.

>  so at that point you can just as well drop in an autostart file, too.
>  
Sure we can, but where is the advantage? If the package is required
anyway we could just leave the file where it is and belongs - with the
benefit that it can be used in other desktops, too.

>  (And in 
>  fact, don't some of the desktops/WMs you have in mind require their own non-
>  XDG autostart setup anyway?) 
Yes, this is something we should try to cover too, but for a start I
suggest to solve the situation for the XDG compliant ones.

>  > Imagine you install gnome-packagekit in Xfce: It will pull in
> say
>  > polkit-gnome but still not work.
>  
>  That's exactly why it's not the app's job to pull in an authentication 
>  agent.  
Which basically means that you don't care about all DEs / WMs in Fedora
being (more or less) broken because we cannot run many of our
system-config-* tools there.

>  (Any application (as opposed to desktop environment / workspace) 
>  package with an explicit Requires on a specific agent is broken and needs to 
>  be fixed.) 
Yes, an application with an explicit requires for a *specific* agent is
broken (and I'm filing bugs like #668156 in this case) but that doesn't
mean that it should not depend on a *generic* agent. If the app cannot
run without the agent, it needs this requirement.

>  > Summing it all up: I still don't see the benefit of the new
> packaging.
>  > polkit-gnome-authentication-agent-1 doesn't start on any 'random'
>  > desktop. Indeed this is a step in the right direction and I appreciate
>  > it because I'm on the receiving side of bugs [1].
>  > 
>  > But wether or not polkit-gnome-authentication-agent-1 starts on any
>  > 'random' desktop has nothing to do with your new packaging but with the
>  > fact that you have switched from "NotShoIn" to "OnlyShowIn". The
> exactly
>  > same effect could be achieved without changing the packaging, so there
>  > is no benefit, but on the other hand it breaks many DEs / WMs that you
>  > might not care about.
>  
>  The OnlyShowIn change would be breaking "random other WMs" anyway, if they 
>  expected polkit-gnome to run. And if not, why do you care where the 
>  autostart file sits? If it's OnlyShowIn=GNOME;, it'll have no effect for you 
>  anyway. 
Please take the time to read my initial proposal or my previous mail. I
said that all agents *but* *one* should have OnlyShowIn. The remaining
one gets "NotShowIn" to not conflict with the others. I suggested this
one to be lxpolkit because it has only a few deps and will be pulled in
by yum if all other providers match of because it's name.

If anybody has a better idea, I am keen to hear it but so far nothing
sounded convincing to me.

Regards,
Christoph

[Kevin Kofler]

Christoph Wickert wrote:
>  Please try to look beyond the rim of your KDE teacup for a moment.
> What
>  about the DEs / WMs that do not provide a polkit agent? Shouldn't we
>  make things like virt-manager just work in *every* environment? 
Well, the DEs which don't provide their own agent should pick one to require 
instead.

>  We could even go one step further and question your approach: I need
> to
>  use some KDE applications and due to the monolithic packaging I also
>  need to install kdebase-workspace. But I never start KDE, so why am I
>  forced to install a second polkit agent then? I have to admit that I
>  don't know the answer to this question and requiring polkit-kde looks
>  like the best solution because my situation is a corner case. 
Well, the real problem there is some apps dragging in kdebase-workspace. In 
principle, libplasma having moved to kdelibs should have solved this, but 
there are still parts of Plasma in kdebase-workspace which get dragged in by 
some plasmoids (which indeed aren't always separately packaged), and there 
are also some other things in kdebase-workspace getting used by some stuff. 
This is quite unfortunate; IMHO, those libs should really move to kdelibs! 
Once we dragged in kdebase-workspace, you're already getting KWin, KDM, 
Plasma etc.; polkit-kde is just a drop in the water. :-(

>  s/the/an. 'The' agent can only be used if there is one.
There should be exactly one which is supposed to run on the desktop you're 
using, otherwise you end up with #657006.

>  Which basically means that you don't care about all DEs / WMs in
> Fedora
>  being (more or less) broken because we cannot run many of our
>  system-config-* tools there. 
I do care. But I think it's their job to actually provide a complete 
environment (through external Requires if necessary), not the application's.

>  Please take the time to read my initial proposal or my previous mail.
> I
>  said that all agents *but* *one* should have OnlyShowIn. The remaining
>  one gets "NotShowIn" to not conflict with the others. I suggested this
>  one to be lxpolkit because it has only a few deps and will be pulled in
>  by yum if all other providers match of because it's name.
>  
>  If anybody has a better idea, I am keen to hear it but so far nothing
>  sounded convincing to me. 
Actually, I don't see anything wrong with the idea of lxpolkit setting 
itself as the agent to run in all the non-GNOME non-KDE desktops, and the 
change mclasen did to polkit-gnome doesn't actually preclude that. (Quite 
the opposite, since there now isn't a second agent trying to run in the same 
desktops.) It's really up to the maintainers of the respective desktops and 
of lxpolkit to decide how they start the polkit agent. As long as your DEs 
actually Require lxpolkit, it doesn't matter whether the autostart file is 
carried in the DE or in lxpolkit itself. (FWIW, we have no plans to move 
polkit-kde's autostart file out of polkit-kde. It's OnlyShowIn=KDE; anyway, 
and the package is required by kdebase-workspace. I don't see a need to fix 
what's not broken.)

What I disagree with is the idea of applications being responsible for 
requiring such a desktop service. This just doesn't work, because they can't 
know which desktop's service should be dragged in.

        Kevin Kofler

[Jaroslav Reznik]

On Saturday, February 26, 2011 04:15:38 pm Kevin Kofler wrote:
>  Christoph Wickert wrote:
>  > Please try to look beyond the rim of your KDE teacup for a moment. What
>  > about the DEs / WMs that do not provide a polkit agent? Shouldn't we
>  > make things like virt-manager just work in *every* environment?
>  
>  Well, the DEs which don't provide their own agent should pick one to
>  require instead.
>  
>  > We could even go one step further and question your approach: I need to
>  > use some KDE applications and due to the monolithic packaging I also
>  > need to install kdebase-workspace. But I never start KDE, so why am I
>  > forced to install a second polkit agent then? I have to admit that I
>  > don't know the answer to this question and requiring polkit-kde looks
>  > like the best solution because my situation is a corner case.
>  
>  Well, the real problem there is some apps dragging in kdebase-workspace. In
>  principle, libplasma having moved to kdelibs should have solved this, but
>  there are still parts of Plasma in kdebase-workspace which get dragged in
>  by some plasmoids (which indeed aren't always separately packaged), and
>  there are also some other things in kdebase-workspace getting used by some
>  stuff. This is quite unfortunate; IMHO, those libs should really move to
>  kdelibs! Once we dragged in kdebase-workspace, you're already getting
>  KWin, KDM, Plasma etc.; polkit-kde is just a drop in the water. :-(
>  
>  > s/the/an. 'The' agent can only be used if there is one.
>  
>  There should be exactly one which is supposed to run on the desktop you're
>  using, otherwise you end up with #657006.
>  
>  > Which basically means that you don't care about all DEs / WMs in Fedora
>  > being (more or less) broken because we cannot run many of our
>  > system-config-* tools there.
>  
>  I do care. But I think it's their job to actually provide a complete
>  environment (through external Requires if necessary), not the
>  application's.
>  
>  > Please take the time to read my initial proposal or my previous mail. I
>  > said that all agents *but* *one* should have OnlyShowIn. The remaining
>  > one gets "NotShowIn" to not conflict with the others. I suggested this
>  > one to be lxpolkit because it has only a few deps and will be pulled in
>  > by yum if all other providers match of because it's name.
>  > 
>  > If anybody has a better idea, I am keen to hear it but so far nothing
>  > sounded convincing to me.
>  
>  Actually, I don't see anything wrong with the idea of lxpolkit setting
>  itself as the agent to run in all the non-GNOME non-KDE desktops, and the
>  change mclasen did to polkit-gnome doesn't actually preclude that. (Quite
>  the opposite, since there now isn't a second agent trying to run in the
>  same desktops.) It's really up to the maintainers of the respective
>  desktops and of lxpolkit to decide how they start the polkit agent. As
>  long as your DEs actually Require lxpolkit, it doesn't matter whether the
>  autostart file is carried in the DE or in lxpolkit itself. (FWIW, we have
>  no plans to move polkit-kde's autostart file out of polkit-kde. It's
>  OnlyShowIn=KDE; anyway, and the package is required by kdebase-workspace.
>  I don't see a need to fix what's not broken.)
>  
>  What I disagree with is the idea of applications being responsible for
>  requiring such a desktop service. This just doesn't work, because they
>  can't know which desktop's service should be dragged in. 
Kevin,
I agree with you - I see polkit agent as integral part of DE. Other DEs/WMs 
makes me worry too, lxpolkit is a sane option.

R.
 
>          Kevin Kofler 
-- 
Jaroslav Řezník <jreznik(a)redhat.com&gt;
Software Engineer - Base Operating Systems Brno

Office: [phone]
Mobile: [phone]
Red Hat, Inc.                               http://cz.redhat.com/

[Bill Nottingham]

Christoph Wickert (christoph.wickert(a)googlemail.com) said: 
>  > anything at all. 
>  
>  Please try to look beyond the rim of your KDE teacup for a moment. What
>  about the DEs / WMs that do not provide a polkit agent? Shouldn't we
>  make things like virt-manager just work in *every* environment?
>  
>  > IMHO, PolicyKit authentication should just be considered a 
>  > basic desktop service which is present in ANY GUI desktop, it's up to the 
>  > desktop environment to Require the proper agent (and up to there, I 
>  > definitely agree with Matthias). In fact, kdebase-workspace already 
>  > Requires: polkit-kde.
>  
>  Again you are arguing from the POV of a full featured DE. Take Xfce for
>  example: It is a very complete environment but still lacks a polkit
>  agent. 
Then it should provide one (even if it's co-opting someone else's), if
it wants to run modern polkit-using apps.

If you're reimplementing the desktop stack... sometimes you have
to reimplement things. It's a fact of life.

Bill