[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Providing polkit policy for update-alternatives?



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 to: