Thursday 2 August 2018

Globally refreshing new group membership - would be needed after some package installations

Hi,
In certain cases package installations will have to set up new groups, mostly for access management.

Examples are:
- libvirt to access /var/run/libvirt/libvirt-sock
- lxd to access /var/lib/lxd/unix.socket
- ... also sometimes accessing files, but you get the pattern

Since logins stay as-is in regard to groups, users have to re-login to pick up those permissions and be able to use the tools.
That is often mitigated by:
- package being preinstalled, so no one realizes the issue
- people deploy a system + set up a recipe automatically and only then log in

But then there are certain cases which just "feel" bad - a.k.a: "why can't it just work after being installed".
Yes a user can easily open a new terminal or kick su/newgrp/... manually !IF! they know what to do.
The next thing that comes to mind is echoing something on install, but who reads those messages - not worth the effort IMHO.
Finally none of these commonly discussed options [1][2][3] will be appropriate to be run from a maintainer-script IMHO.
Nor would they fixup the Graphical UI that represents a login as well.

Please get me right, I have every now and then seen issues of "this kind" and they are often not a big deal - so triage all of those ->wishlist and ignore them, not really.
But I find it annoying since we spent so much to make Ubuntu easy to consume and having such rough edges left.

I was wondering if there is a common pattern to resolve this that might just be unknown to me yet and that I could use in packaging.
OTOH I can already feel the security concerns and bad side effects of "global group membership refreshes"
And if there would be a common pattern that really works well - we should probably think of a single dh_group_refresh or something like it instead of per package fixes.
Posted by at