Re: Providing polkit policy for update-alternatives?
在 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
Reply to: