Providing polkit policy for update-alternatives?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Providing polkit policy for update-alternatives?

073plan
[ Please CC me and/or CC [hidden email], thanks ]

Hello dpkg people,

I am currently working on Debian package "galternatives" [1], the graphical
front-end to the update-alternatives program which is shipped by dpkg package.

It seems that some actions in /usr/bin/update-alternatives will modify system
files thus requires admin privileges. When called from shell, people often use
sudo or su to gain such privilege. However, with a graphical program like
galternatives, running graphical appliations directly with privilege is risky.
The best approach is to gain privilege only when update-alternatives is called
as a subprocess.

The old method is to use gksu. However, gksu is to be removed in buster cycle.
[2] We intend to use polkit instead in future releases. However, using polkit
(to be concrete, using pkexec(1)) requires putting policy XML files under
 /usr/share/polkit-1/actions/ [3]. Since update-alternatives is actually
provided by dpkg, I am asking in debian-dpkg list here.

I think there are two viable options:

* Let galternatives ship org.debian.pkexec.update-alternatives.policy
* Let dpkg package ship org.debian.pkexec.update-alternatives.policy

Once the policy file gets settled down in the system, policykit will be invoked
when "pkexec update-alternatives [options...]" is called. Only users with
admin priviliges are allowed to proceed (with their own password checked) and
such privilege promotion will last for a short while ("auth_admin_keep") with
the help of policykit.

I am wondering which one do you prefer. Any suggestions would be welcome too.

* * * * *

A draft for the file should be like this:

(/usr/share/polkit-1/actions/org.debian.pkexec.update-alternatives.policy)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>
  <vendor>galternatives</vendor>
  <vendor_url>https://tracker.debian.org/pkg/galternatives</vendor_url>
  <icon_name>galternatives</icon_name>

  <action id="org.debian.pkexec.update-alternatives">
    <description>Run update-alternatives tool to modify system alternative
selections</description>
    <description xml:lang="zh_CN">运行 update-alternatives 工具以修改系统可选项配置</
description>
    <message>Authentication is required to run update-alternatives tool</
message>
    <message xml:lang="zh_CN">运行 update-alternatives 工具需要认证</message>
    <message xml:lang="zh_HK">執行 update-alternatives 工具前要先認證</message>
    <message xml:lang="zh_TW">需要驗證以執行 update-alternatives 工具</message>
    <defaults>
      <allow_any>auth_admin_keep</allow_any>
      <allow_inactive>auth_admin_keep</allow_inactive>
      <allow_active>auth_admin_keep</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/update-
alternatives</annotate>
  </action>

</policyconfig>

[1] https://tracker.debian.org/pkg/galternatives
[2] https://bugs.debian.org/867236
[3] man 8 polkit

Thanks,
Boyuan Yang

Reply | Threaded
Open this post in threaded view
|

Re: Providing polkit policy for update-alternatives?

073plan
在 2017年8月16日星期三 CST 下午3:22:55,Boyuan Yang 写道:

> [ Please CC me and/or CC [hidden email], thanks ]
>
> Hello dpkg people,
>
> I am currently working on Debian package "galternatives" [1], the graphical
> front-end to the update-alternatives program which is shipped by dpkg
> package.
>
> It seems that some actions in /usr/bin/update-alternatives will modify
> system files thus requires admin privileges. When called from shell, people
> often use sudo or su to gain such privilege. However, with a graphical
> program like galternatives, running graphical appliations directly with
> privilege is risky. The best approach is to gain privilege only when
> update-alternatives is called as a subprocess.
>
> The old method is to use gksu. However, gksu is to be removed in buster
> cycle. [2] We intend to use polkit instead in future releases. However,
> using polkit (to be concrete, using pkexec(1)) requires putting policy XML
> files under /usr/share/polkit-1/actions/ [3]. Since update-alternatives is
> actually provided by dpkg, I am asking in debian-dpkg list here.
>
> I think there are two viable options:
>
> * Let galternatives ship org.debian.pkexec.update-alternatives.policy
> * Let dpkg package ship org.debian.pkexec.update-alternatives.policy
>
> Once the policy file gets settled down in the system, policykit will be
> invoked when "pkexec update-alternatives [options...]" is called. Only
> users with admin priviliges are allowed to proceed (with their own password
> checked) and such privilege promotion will last for a short while
> ("auth_admin_keep") with the help of policykit.
>
> I am wondering which one do you prefer. Any suggestions would be welcome
> too.
>
> * * * * *
>
> A draft for the file should be like this:
>
> (/usr/share/polkit-1/actions/org.debian.pkexec.update-alternatives.policy)
>
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE policyconfig PUBLIC
>  "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
>  "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
> <policyconfig>
>   <vendor>galternatives</vendor>
>   <vendor_url>https://tracker.debian.org/pkg/galternatives</vendor_url>
>   <icon_name>galternatives</icon_name>
>
>   <action id="org.debian.pkexec.update-alternatives">
>     <description>Run update-alternatives tool to modify system alternative
> selections</description>
>     <description xml:lang="zh_CN">运行 update-alternatives 工具以修改系统可选项配置</
> description>
>     <message>Authentication is required to run update-alternatives tool</
> message>
>     <message xml:lang="zh_CN">运行 update-alternatives 工具需要认证</message>
>     <message xml:lang="zh_HK">執行 update-alternatives 工具前要先認證</message>
>     <message xml:lang="zh_TW">需要驗證以執行 update-alternatives 工具</message>
>     <defaults>
>       <allow_any>auth_admin_keep</allow_any>
>       <allow_inactive>auth_admin_keep</allow_inactive>
>       <allow_active>auth_admin_keep</allow_active>
>     </defaults>
>     <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/update-
> alternatives</annotate>
>   </action>
>
> </policyconfig>
>
> [1] https://tracker.debian.org/pkg/galternatives
> [2] https://bugs.debian.org/867236
> [3] man 8 polkit
>
> Thanks,
> Boyuan Yang

Seems that no one replied these days. I will start shipping policykit policy
for update-alternatives with "galternatives" package in experimental soon and
unstable later. Please contact me were there any doubts.

Regards,
Boyuan Yang

Reply | Threaded
Open this post in threaded view
|

Re: Providing polkit policy for update-alternatives?

Guillem Jover
Hi!

On Sun, 2017-08-20 at 20:47:56 +0800, Boyuan Yang wrote:

> 在 2017年8月16日星期三 CST 下午3:22:55,Boyuan Yang 写道:
> > It seems that some actions in /usr/bin/update-alternatives will modify
> > system files thus requires admin privileges. When called from shell, people
> > often use sudo or su to gain such privilege. However, with a graphical
> > program like galternatives, running graphical appliations directly with
> > privilege is risky. The best approach is to gain privilege only when
> > update-alternatives is called as a subprocess.
> >
> > The old method is to use gksu. However, gksu is to be removed in buster
> > cycle. [2] We intend to use polkit instead in future releases. However,
> > using polkit (to be concrete, using pkexec(1)) requires putting policy XML
> > files under /usr/share/polkit-1/actions/ [3]. Since update-alternatives is
> > actually provided by dpkg, I am asking in debian-dpkg list here.

Hmm I've considered for some time providing a shared library for u-a,
but I guess that you'd still want to call the tool to perform the
privileged actions?

> > I think there are two viable options:
> >
> > * Let galternatives ship org.debian.pkexec.update-alternatives.policy
> > * Let dpkg package ship org.debian.pkexec.update-alternatives.policy
> >
> > Once the policy file gets settled down in the system, policykit will be
> > invoked when "pkexec update-alternatives [options...]" is called. Only
> > users with admin priviliges are allowed to proceed (with their own password
> > checked) and such privilege promotion will last for a short while
> > ("auth_admin_keep") with the help of policykit.
> >
> > I am wondering which one do you prefer. Any suggestions would be welcome
> > too.

I think the correct thing to do is for dpkg to provide that file,
because perhaps kalernatives or other similar tools want to make use
of it, and I'm not sure how policykit reacts when there's the same
policy provided by several packages. Also the absolute tools path is
used, and that should come from the package providing the tool as that
has already changed in the past, or it might be different on other
downstreams.

I started looking into what merging this would imply the other day,
and the first thing I noticed is that there's no DTD for the format
(#872615). I was also checking how to handle translations, I might use
po4a and merged them on the generated file or similar. In any case
I've a got a preliminary patch, which should get merged for 1.19.0.

> > A draft for the file should be like this:
> >
> > (/usr/share/polkit-1/actions/org.debian.pkexec.update-alternatives.policy)
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <!DOCTYPE policyconfig PUBLIC
> >  "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
> >  "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
> > <policyconfig>
> >   <vendor>galternatives</vendor>
> >   <vendor_url>https://tracker.debian.org/pkg/galternatives</vendor_url>
> >   <icon_name>galternatives</icon_name>
> >
> >   <action id="org.debian.pkexec.update-alternatives">
> >     <description>Run update-alternatives tool to modify system alternative
> > selections</description>
> >     <description xml:lang="zh_CN">运行 update-alternatives 工具以修改系统可选项配置</
> > description>
> >     <message>Authentication is required to run update-alternatives tool</
> > message>
> >     <message xml:lang="zh_CN">运行 update-alternatives 工具需要认证</message>
> >     <message xml:lang="zh_HK">執行 update-alternatives 工具前要先認證</message>
> >     <message xml:lang="zh_TW">需要驗證以執行 update-alternatives 工具</message>
> >     <defaults>
> >       <allow_any>auth_admin_keep</allow_any>
> >       <allow_inactive>auth_admin_keep</allow_inactive>
> >       <allow_active>auth_admin_keep</allow_active>
> >     </defaults>
> >     <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/update-
> > alternatives</annotate>
> >   </action>
> > </policyconfig>

Thanks for this initial proposal, it was very useful as a starting point!

Regards,
Guillem

Reply | Threaded
Open this post in threaded view
|

Re: Providing polkit policy for update-alternatives?

073plan
在 2017年8月21日星期一 CST 上午1:49:36,Guillem Jover 写道:

> Hi!
>
> On Sun, 2017-08-20 at 20:47:56 +0800, Boyuan Yang wrote:
> > 在 2017年8月16日星期三 CST 下午3:22:55,Boyuan Yang 写道:
> >
> > > It seems that some actions in /usr/bin/update-alternatives will modify
> > > system files thus requires admin privileges. When called from shell,
> > > people
> > > often use sudo or su to gain such privilege. However, with a graphical
> > > program like galternatives, running graphical appliations directly with
> > > privilege is risky. The best approach is to gain privilege only when
> > > update-alternatives is called as a subprocess.
> > >
> > > The old method is to use gksu. However, gksu is to be removed in buster
> > > cycle. [2] We intend to use polkit instead in future releases. However,
> > > using polkit (to be concrete, using pkexec(1)) requires putting policy
> > > XML
> > > files under /usr/share/polkit-1/actions/ [3]. Since update-alternatives
> > > is
> > > actually provided by dpkg, I am asking in debian-dpkg list here.
>
> Hmm I've considered for some time providing a shared library for u-a,
> but I guess that you'd still want to call the tool to perform the
> privileged actions?

A shared library should be okay but I have no idea where should a general
application escalate its privilege if it is going to use the shared library.
Should it happen *before* calling the function inside the library or *inside*
the library?

Such problem is clearer when using a separate binary executable (/usr/bin/
update-alternatives here) since pkexec handles it well.


> > > I think there are two viable options:
> > >
> > > * Let galternatives ship org.debian.pkexec.update-alternatives.policy
> > > * Let dpkg package ship org.debian.pkexec.update-alternatives.policy
> > >
> > > Once the policy file gets settled down in the system, policykit will be
> > > invoked when "pkexec update-alternatives [options...]" is called. Only
> > > users with admin priviliges are allowed to proceed (with their own
> > > password
> > > checked) and such privilege promotion will last for a short while
> > > ("auth_admin_keep") with the help of policykit.
> > >
> > > I am wondering which one do you prefer. Any suggestions would be welcome
> > > too.
>
> I think the correct thing to do is for dpkg to provide that file,
> because perhaps kalernatives or other similar tools want to make use
> of it, and I'm not sure how policykit reacts when there's the same
> policy provided by several packages. Also the absolute tools path is
> used, and that should come from the package providing the tool as that
> has already changed in the past, or it might be different on other
> downstreams.

Sure. If dpkg package is going to provide this policy file, it should be the
sole provider of the policy around update-alternatives tool.
 
> I started looking into what merging this would imply the other day,
> and the first thing I noticed is that there's no DTD for the format
> (#872615). I was also checking how to handle translations, I might use
> po4a and merged them on the generated file or similar. In any case
> I've a got a preliminary patch, which should get merged for 1.19.0.

I have seen previous attempts of handling translation for various XMLs using
intltool (description says "Utility scripts for internationalizing XML"). Hope
that helps.

As for the DTD, we should remind upstream (policykit) to provide a proper DTD
file at the given URL ("http://www.freedesktop.org/standards/PolicyKit/1.0/
policyconfig.dtd").

There is a spec for the file as provided here [1]. I believe one familiar with
XML should be able to write a proper DTD file within a day with the words from
the spec.

[1] https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html

> > > A draft for the file should be like this:
> > >
> > > (/usr/share/polkit-1/actions/org.debian.pkexec.update-alternatives.polic
> > > y)
> > >
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <!DOCTYPE policyconfig PUBLIC
> > >
> > >  "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
> > >  "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
> > >
> > > <policyconfig>
> > >
> > >   <vendor>galternatives</vendor>
> > >   <vendor_url>https://tracker.debian.org/pkg/galternatives</vendor_url>
> > >   <icon_name>galternatives</icon_name>
> > >  
> > >   <action id="org.debian.pkexec.update-alternatives">
> > >  
> > >     <description>Run update-alternatives tool to modify system
> > >     alternative
> > >
> > > selections</description>
> > >
> > >     <description xml:lang="zh_CN">运行 update-alternatives 工具以修改系统可选项配置</
> > >
> > > description>
> > >
> > >     <message>Authentication is required to run update-alternatives
> > >     tool</
> > >
> > > message>
> > >
> > >     <message xml:lang="zh_CN">运行 update-alternatives 工具需要认证</message>
> > >     <message xml:lang="zh_HK">執行 update-alternatives 工具前要先認證</message>
> > >     <message xml:lang="zh_TW">需要驗證以執行 update-alternatives 工具</message>
> > >     <defaults>
> > >    
> > >       <allow_any>auth_admin_keep</allow_any>
> > >       <allow_inactive>auth_admin_keep</allow_inactive>
> > >       <allow_active>auth_admin_keep</allow_active>
> > >    
> > >     </defaults>
> > >     <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/update-
> > >
> > > alternatives</annotate>
> > >
> > >   </action>
> > >
> > > </policyconfig>
>
> Thanks for this initial proposal, it was very useful as a starting point!

Thanks. I'll wait and watch the progress.

Regards,
Boyuan Yang