[arch-general] How to enable Archlinux users to easily avoid Polkit?

newer
[arch-general] blk_update_request:...

Neven Sajko

29 May 2021 29 May '21

11:11 a.m.

Hi On my up-to-date Archlinux system, the only package that depends on Polkit is Colord, which, in turn, is only depended on by GTK3. Forcefully removing the Polkit package (with pacman -R --assume-installed polkit polkit), works fine: after doing it, I rebooted and printed a page from Chromium (which uses GTK3 for this) on my black-and-white printer over USB. It would be very nice to give Arch and GTK3 users like me the opportunity to avoid Polkit without hassle. The only idea I got is to move polkit from depends to optdepends in the colord package, and add post_install and post_upgrade messages saying something like:

...

WARNING: install polkit if you plan on actually using colord!

Do others agree that this would be more good than bad? In any case, I'm not a Pacman expert, so I'm hoping somebody can come up with an even better solution? Tangentially, what are the chances of convincing upstream to relax the Colord dependency on Polkit? Could such a patch get accepted? BTW, does somebody know what happened to the packages for building GTK3 without Colord, building Colord without Polkit, and similar? I think those were available on AUR previosuly. Regards, Neven

Show replies by date

Ralf Mardorf

29 May 29 May

2:25 p.m.

Hi, I build empty dummy packages to fulfil dependencies related to gvfs and pulseaudio, since I don't need gvfs and pulseaudio and I don't want to suffer from all the issues that gvfs and pulseaudio do cause for my computer usage. Use a high value for epoch and/or pkgver. I for example build with "Version" 2013.08.18-1 in 2013 and since then never run into another issue, other than the need to build an empty dummy package for pulseaudio-bluetooth in 2017, when pulseaudio-bluetooth enforced a dedicated version of pulseaudio, as hard dependency. Non of the software that has got gvfs or pulseaudio as a hard dependency, ever failed for my needs in probably way more than just 8 years. Regards, Ralf

Nick Shvelidze

2:32 p.m.

...

The only idea I got is to move polkit from depends to optdepends in the colord package, and add post_install and post_upgrade messages saying something like:

...
WARNING: install polkit if you plan on actually using colord!

Do others agree that this would be more good than bad? In any case, I'm not a Pacman expert, so I'm hoping somebody can come up with an even better solution?

I don't think this is a good idea, the only solution I can think of is to separate libcolord from colord and have GTK depend on libcolord, like on Debian On Sat, May 29, 2021 at 3:11 PM Neven Sajko via arch-general wrote:

...

Hi

On my up-to-date Archlinux system, the only package that depends on Polkit is Colord, which, in turn, is only depended on by GTK3.

Forcefully removing the Polkit package (with pacman -R --assume-installed polkit polkit), works fine: after doing it, I rebooted and printed a page from Chromium (which uses GTK3 for this) on my black-and-white printer over USB.

It would be very nice to give Arch and GTK3 users like me the opportunity to avoid Polkit without hassle.

The only idea I got is to move polkit from depends to optdepends in the colord package, and add post_install and post_upgrade messages saying something like:

...
WARNING: install polkit if you plan on actually using colord!

Do others agree that this would be more good than bad? In any case, I'm not a Pacman expert, so I'm hoping somebody can come up with an even better solution?

Tangentially, what are the chances of convincing upstream to relax the Colord dependency on Polkit? Could such a patch get accepted?

BTW, does somebody know what happened to the packages for building GTK3 without Colord, building Colord without Polkit, and similar? I think those were available on AUR previosuly.

Regards, Neven

Ralf Mardorf

2:56 p.m.

On Sat, 29 May 2021 18:32:29 +0400, Nick Shvelidze via arch-general wrote:

...

...
The only idea I got is to move polkit from depends to optdepends in the colord package, and add post_install and post_upgrade messages saying something like:

...
WARNING: install polkit if you plan on actually using colord!

Do others agree that this would be more good than bad? In any case, I'm not a Pacman expert, so I'm hoping somebody can come up with an even better solution?

I don't think this is a good idea, the only solution I can think of is to separate libcolord from colord and have GTK depend on libcolord, like on Debian

Btw. I'm not that allergic to polkit as the OP is. It's installed on my machine, but actually not working for all packages. However, it likely is useful for some software I'm using and it doesn't matter that it fails for some other software, that I anyway use or used with root privileges via command line, ocztoolbox comes to mind, a package from AUR, still installed, but I'm anyway in favour of running /usr/local/bin/kioxia_ssd_utility/SSDUtility, since ocztoolbox doesn't show my new kioxia ssds, while /usr/local/bin/kioxia_ssd_utility/SSDUtility does show them and the old ocz ssds, too. If I should have missed, that polkit is also not useful for my usage, then it at least doesn't harm my computer usage, so I don't feel the need to remove it by a workaround. _But_ there are a lot of packages that require at least gvfs or pulseaudio as a hard dependency, while those packages could require them as an optional dependency instead, they still would work. Making them a hard dependency could be an issue for some computer usage. I can't comment on polkit, other than some packges depend on it, but polkit still doesn't do it's job for some of those packages.

Neven Sajko

30 May 30 May

9:54 p.m.

On Sat, 29 May 2021 at 14:56, Ralf Mardorf via arch-general wrote:

...

_But_ there are a lot of packages that require at least gvfs or pulseaudio as a hard dependency, while those packages could require them as an optional dependency instead, they still would work.

I guess that if you reported a bug for any of those packages on https://bugs.archlinux.org, the packagers would probably move pulseaudio/gvfs from depends to optdepends. I've had success with that in the past. Regards, Neven

Neven Sajko

10:40 p.m.

Regarding splitting the colord package, I made a feature request for that now; but in the meantime I have a dummy package pretending to be polkit. In case someone finds it useful, the PKGBUILD is just these 5 lines: pkgname=dummy-polkit pkgver=1 pkgrel=1 arch=(any) provides=(polkit=99:99999)

Eli Schwartz

2:51 a.m.

On 5/29/21 7:11 AM, Neven Sajko via arch-general wrote:

...

Hi

On my up-to-date Archlinux system, the only package that depends on Polkit is Colord, which, in turn, is only depended on by GTK3.

Forcefully removing the Polkit package (with pacman -R --assume-installed polkit polkit), works fine: after doing it, I rebooted and printed a page from Chromium (which uses GTK3 for this) on my black-and-white printer over USB.

/usr/lib/gtk-3.0/3.0.0/printbackends/libprintbackend-cups.so directly links to libcolord and will fail to load if it is unavailable. But perhaps you used a different printbackend... (I don't know enough about gtk3 to say whether making shared libraries for printbackends into optional deps, is reasonable. If gtk3 is able to gracefully handle printbackends which fail to load, then it should be fine to change...)

...

It would be very nice to give Arch and GTK3 users like me the opportunity to avoid Polkit without hassle.

The only idea I got is to move polkit from depends to optdepends in the colord package, and add post_install and post_upgrade messages saying something like:

...
WARNING: install polkit if you plan on actually using colord!

Do others agree that this would be more good than bad? In any case, I'm not a Pacman expert, so I'm hoping somebody can come up with an even better solution?

This is improper, the correct pacman solution for colord would be to do as Nick suggested and build a split package for: - libcolord to satisfy programs linking to colord - colord to run the daemon which libcolord tries to send messages to

...

Tangentially, what are the chances of convincing upstream to relax the Colord dependency on Polkit? Could such a patch get accepted?

idk how that would work, since /usr/bin/colord has a shared library link to libpolkit-gobject-1.so.0 And back in mid 2017 they completely removed support for building colord with --disable-polkit, as well as the warning if you did so, which said: "YOU ARE NOT USING A SECURE DAEMON. ALL USERS CAN DO ANYTHING!" during configure.

...

BTW, does somebody know what happened to the packages for building GTK3 without Colord, building Colord without Polkit, and similar? I think those were available on AUR previosuly.

I didn't stumble across any relevant deletion requests. What were the exact package names? -- Eli Schwartz Bug Wrangler and Trusted User

Neven Sajko

12:32 p.m.

On Sun, 30 May 2021 at 02:51, Eli Schwartz via arch-general wrote:

...

/usr/lib/gtk-3.0/3.0.0/printbackends/libprintbackend-cups.so directly links to libcolord and will fail to load if it is unavailable. But perhaps you used a different printbackend...

I don't have LPRNG, so CUPS must have been used AFAIK. Also note that I deleted just the polkit package from my system, NOT the colord package.

...

- libcolord to satisfy programs linking to colord - colord to run the daemon which libcolord tries to send messages to

I hope the colord package gets split, then!

...

idk how that would work, since /usr/bin/colord has a shared library link to libpolkit-gobject-1.so.0

I thought maybe dlopen could be used instead.

...

...
BTW, does somebody know what happened to the packages for building GTK3 without Colord, building Colord without Polkit, and similar? I think those were available on AUR previosuly.

I didn't stumble across any relevant deletion requests. What were the exact package names?

I just checked the history of the GTK wiki page, and back in September 2017 these relevant packages were on AUR, none of which seem to exist now: gtk3-light gtk3-nobroadway-nowayland-nocolord gtk3-print-backends-nocolord colord-nopolkit Thanks, Neven

NTS

2:47 p.m.

Dear All, I agree totally to cut down on dependencies and unused daemons to reduce attack surface. Feel free to upvote this CUPS issue about its colord dependency upstream: https://github.com/OpenPrinting/cups/issues/193 BTW if the polkit service is not running then libvirtd won't start VMs (as root by virsh interface). Sometimes also `systemd` will not shut down or reboot the system when asked to (it checks by using polkit whether root may shutdown/reboot the system lol). Best regards, NTS On Sun, 30 May 2021 at 12:32, Neven Sajko via arch-general wrote:

...

On Sun, 30 May 2021 at 02:51, Eli Schwartz via arch-general wrote:

...
/usr/lib/gtk-3.0/3.0.0/printbackends/libprintbackend-cups.so directly links to libcolord and will fail to load if it is unavailable. But perhaps you used a different printbackend...

I don't have LPRNG, so CUPS must have been used AFAIK. Also note that I deleted just the polkit package from my system, NOT the colord package.

...
- libcolord to satisfy programs linking to colord - colord to run the daemon which libcolord tries to send messages to

I hope the colord package gets split, then!

...
idk how that would work, since /usr/bin/colord has a shared library link to libpolkit-gobject-1.so.0

I thought maybe dlopen could be used instead.

...
...
BTW, does somebody know what happened to the packages for building GTK3 without Colord, building Colord without Polkit, and similar? I think those were available on AUR previosuly.

I didn't stumble across any relevant deletion requests. What were the exact package names?

I just checked the history of the GTK wiki page, and back in September 2017 these relevant packages were on AUR, none of which seem to exist now: gtk3-light gtk3-nobroadway-nowayland-nocolord gtk3-print-backends-nocolord colord-nopolkit

Thanks, Neven

Eli Schwartz

6:35 p.m.

On 5/30/21 8:32 AM, Neven Sajko wrote:

...

On Sun, 30 May 2021 at 02:51, Eli Schwartz via arch-general wrote:

...
/usr/lib/gtk-3.0/3.0.0/printbackends/libprintbackend-cups.so directly links to libcolord and will fail to load if it is unavailable. But perhaps you used a different printbackend...

I don't have LPRNG, so CUPS must have been used AFAIK. Also note that I deleted just the polkit package from my system, NOT the colord package.

...
- libcolord to satisfy programs linking to colord - colord to run the daemon which libcolord tries to send messages to

I hope the colord package gets split, then!

...
idk how that would work, since /usr/bin/colord has a shared library link to libpolkit-gobject-1.so.0

I thought maybe dlopen could be used instead.

I somehow doubt this would help given that the colord daemon actually attempts to use it for all functionality, seemingly. Package splitting would work much better... given the fairly high cost of the js78 package. I'm not sure why gtk3 depends on it at all, though. In https://bugs.archlinux.org/task/50513 the print backends got split out into the package gtk3-print-backends, until 3.22.26+47+g3a1a7135a2-1 when that got merged back into the main package without a commit message.

...

...
...
BTW, does somebody know what happened to the packages for building GTK3 without Colord, building Colord without Polkit, and similar? I think those were available on AUR previosuly.

I didn't stumble across any relevant deletion requests. What were the exact package names?

I just checked the history of the GTK wiki page, and back in September 2017 these relevant packages were on AUR, none of which seem to exist now: gtk3-light gtk3-nobroadway-nowayland-nocolord gtk3-print-backends-nocolord colord-nopolkit

None of them have been maintained in the last 4 years, so they were most likely deleted due to not working. alternatively they got deleted due to the aforementioned gtk3-print-backends split package being implemented? -- Eli Schwartz Bug Wrangler and Trusted User

Neven Sajko

10:50 p.m.

1076

Age (days ago)

1077

Last active (days ago)

List overview

Download

10 comments

5 participants

participants (5)

Eli Schwartz
Neven Sajko
Nick Shvelidze
NTS
Ralf Mardorf

[arch-general] How to enable Archlinux users to easily avoid Polkit?

tags

participants (5)