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

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

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

Christian Ehrhardt
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.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Robie Basak-4
On Thu, Aug 02, 2018 at 01:16:04PM +0200, Christian Ehrhardt wrote:
> 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.

I have in mind to write a wrapper that checks if "newgrp" or "sg" would
succeed and exec itself via that if so. I'm not aware of this being an
existing pattern though.

If we wanted to make it a standard thing, we could provide such a
wrapper in a package and then packages that wanted to use it could
register with (and symlink to) the wrapper.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Christian Ehrhardt


On Thu, Aug 2, 2018 at 1:32 PM Robie Basak <[hidden email]> wrote:
On Thu, Aug 02, 2018 at 01:16:04PM +0200, Christian Ehrhardt wrote:
> 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.

I have in mind to write a wrapper that checks if "newgrp" or "sg" would
succeed and exec itself via that if so. I'm not aware of this being an
existing pattern though.

If we wanted to make it a standard thing, we could provide such a
wrapper in a package and then packages that wanted to use it could
register with (and symlink to) the wrapper.

If working this could maybe fixup the terminal it is running in but not more than that.
- New terminals started from UI might still have old group membership (if not a new login)
- And the UI itself when click-starting things will not have changed

I'm a console guy myself, but that would only only fix part of the problem :-/
Especially as the console-addicted folks are those who would mostly have known "that they have to" and "how to" refresh their groups.


--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Robie Basak-4
On Fri, Aug 03, 2018 at 12:13:30PM +0200, Christian Ehrhardt wrote:
> If working this could maybe fixup the terminal it is running in but not
> more than that.

Yes - it would be limited in scope. But for CLI tools (say lxc), if lxc
is wrapped with newgrp, then it should be sufficient.

> - And the UI itself when click-starting things will not have changed

Yeah, so for example starting virt-manager from the desktop shell will
continue to be a problem until the next login session. Do you have any
solution in mind for this? Apart from something quite invasive (eg.
getting the desktop shell to re-exec itself via newgrp, or ptrace except
that's disabled by default, etc, or not using groups, or kernel support
for messing with group membership of other processes, and/or something
that walks a cgroup modifying group memberships) I don't see any
solution.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Christian Ehrhardt


On Fri, Aug 3, 2018 at 1:13 PM Robie Basak <[hidden email]> wrote:
On Fri, Aug 03, 2018 at 12:13:30PM +0200, Christian Ehrhardt wrote:
[...] 
> - And the UI itself when click-starting things will not have changed

Yeah, so for example starting virt-manager from the desktop shell will
continue to be a problem until the next login session. Do you have any
solution in mind for this?

No better idea, which was why I was asking for the Mass-Intelligence of Ubuntu-Devel :-)


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Robie Basak-4
In reply to this post by Robie Basak-4
On Fri, Aug 03, 2018 at 12:13:15PM +0100, Robie Basak wrote:
> Yeah, so for example starting virt-manager from the desktop shell will
> continue to be a problem until the next login session.

Actually, now that I think about it, we could adjust the desktop file to
use a wrapper there also.

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Christian Ehrhardt


On Fri, Aug 3, 2018 at 3:28 PM Robie Basak <[hidden email]> wrote:
On Fri, Aug 03, 2018 at 12:13:15PM +0100, Robie Basak wrote:
> Yeah, so for example starting virt-manager from the desktop shell will
> continue to be a problem until the next login session.

Actually, now that I think about it, we could adjust the desktop file to
use a wrapper there also.

We will have a discussion on the sprint, but in some experiments I found why I think this is no (good) solution.

The reason is that the fix is not bound to the place of the issue.
Take the libvirt example which would make some users member of group libvirt on install.
- The trigger is in installing libvirt package
- But the fix would be in virt-manager, uvtool, ... how many more?
- People might wonder why one works but not the other

The lack of a better solution might make us use it in some places (Those that matter to users most) still, but I wanted to put words to my concerns :-)


--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel