Re: USERGROUPS_ENAB broke virtualbox guest tools (was: New Tumbleweed snapshot 20211218 released!)
On 12/28/21 11:38, Andrei Borzenkov wrote:
Virtualbox guest tools set /dev/vboxuser to 0660 root:users. New users no more belong to the users group and do not have access to this device.
Maybe guest tools should enable access for logged in user (TAG+="uaccess") instead.
My first inclination is to create /dev/vboxuser as 0660 root:vboxusers the save as /dev/vboxsf. If that does not work, I will check your suggested method. Larry
On Wed, Dec 29, 2021 at 12:51 AM Larry Finger
On 12/28/21 11:38, Andrei Borzenkov wrote:
Virtualbox guest tools set /dev/vboxuser to 0660 root:users. New users no more belong to the users group and do not have access to this device.
Maybe guest tools should enable access for logged in user (TAG+="uaccess") instead.
My first inclination is to create /dev/vboxuser as 0660 root:vboxusers the save as /dev/vboxsf. If that does not work, I will check your suggested method.
This means every user in a guest system has to belong to the vboxsf group which is certainly not default and defeats the idea of having normal installation under VB. Besides having this device accessible to multiple users has potential security implications allowing other users to snoop shared clipboard content. /dev/vboxuser is used by VBoxClient which is started as part of (currently, only X11) user sessions. So it is just natural to automatically provide access to the currently logged in user and *only* to this user.
On 12/29/21 00:47, Andrei Borzenkov wrote:
This means every user in a guest system has to belong to the vboxsf group which is certainly not default and defeats the idea of having normal installation under VB. Besides having this device accessible to multiple users has potential security implications allowing other users to snoop shared clipboard content.
/dev/vboxuser is used by VBoxClient which is started as part of (currently, only X11) user sessions. So it is just natural to automatically provide access to the currently logged in user and *only* to this user.
I meant "in the manner of vboxsf." The actual group would be vboxusers. Every user of VirtualBox already must be a member of this group. Larry
On Wed, Dec 29, 2021 at 10:15 AM Larry Finger
On 12/29/21 00:47, Andrei Borzenkov wrote:
This means every user in a guest system has to belong to the vboxsf group which is certainly not default and defeats the idea of having normal installation under VB. Besides having this device accessible to multiple users has potential security implications allowing other users to snoop shared clipboard content.
/dev/vboxuser is used by VBoxClient which is started as part of (currently, only X11) user sessions. So it is just natural to automatically provide access to the currently logged in user and *only* to this user.
I meant "in the manner of vboxsf." The actual group would be vboxusers. Every user of VirtualBox already must be a member of this group.
Sorry? What exactly does "user of VirtualBox" mean? We are talking about the *guest* system. Guest system does not have "VirtualBox users" at all, it has normal users created as part of installation. And normal installation most certainly does not add users to "vboxusers" group. You seem to think about the host system. The problem is inside the guest system.
On 12/29/21 02:17, Andrei Borzenkov wrote:
Sorry? What exactly does "user of VirtualBox" mean? We are talking about the *guest* system. Guest system does not have "VirtualBox users" at all, it has normal users created as part of installation. And normal installation most certainly does not add users to "vboxusers" group.
You seem to think about the host system. The problem is inside the guest system.
Sorry that I was so dense. The creation of /dev/vboxusers comes the the line KERNEL=="vboxuser", NAME="vboxuser", OWNER="root", GROUP="users", MODE="0660" in /usr/lib/udev/rules.d/60-vboxguest.rules. Changing that line to KERNEL=="vboxuser", NAME="vboxuser", OWNER="root", MODE="0660" , TAG+="uaccess" results in a /dev/vboxuser as 0660 root:root, but it works without the user belonging to any group other than the default assigned when the system was installed. I think that is what you meant for me to do. That said, I have no idea how it works. More learning to do. Thanks, Larry
On Thu, Dec 30, 2021 at 8:34 AM Larry Finger
On 12/29/21 02:17, Andrei Borzenkov wrote:
Sorry? What exactly does "user of VirtualBox" mean? We are talking about the *guest* system. Guest system does not have "VirtualBox users" at all, it has normal users created as part of installation. And normal installation most certainly does not add users to "vboxusers" group.
You seem to think about the host system. The problem is inside the guest system.
Sorry that I was so dense. The creation of /dev/vboxusers comes the the line KERNEL=="vboxuser", NAME="vboxuser", OWNER="root", GROUP="users", MODE="0660" in /usr/lib/udev/rules.d/60-vboxguest.rules.
Changing that line to KERNEL=="vboxuser", NAME="vboxuser", OWNER="root", MODE="0660" , TAG+="uaccess" results in a /dev/vboxuser as 0660 root:root, but it works without the user belonging to any group other than the default assigned when the system was installed.
I think that is what you meant for me to do.
Yes, I use this on my (the only available) TW VM under VirtualBox and it allows me to use the shared clipboard again for users created on current TW.
That said, I have no idea how it works. More learning to do.
systemd-logind adds ACLs to allow access to currently logged in user. Note that it also revokes access when switching between users and VirtualBox tools may not expect it.
On 12/30/21 06:34, Andrei Borzenkov wrote:
systemd-logind adds ACLs to allow access to currently logged in user. Note that it also revokes access when switching between users and VirtualBox tools may not expect it.
To test this, I created a second user on my VM. I was quite surprised to discover that the new one belonged to group "users". It seems that YaST is behaving differently than the installer. In any case, I was able to switch between users with no problems. Thanks for your help, Larry
On Thu, Dec 30, 2021 at 10:04 PM Larry Finger
On 12/30/21 06:34, Andrei Borzenkov wrote:
systemd-logind adds ACLs to allow access to currently logged in user. Note that it also revokes access when switching between users and VirtualBox tools may not expect it.
To test this, I created a second user on my VM. I was quite surprised to discover that the new one belonged to group "users". It seems that YaST is behaving differently than the installer. In any case, I was able to switch between users with no problems.
You are right, YaST still defaults to assigning "users" as the primary user group. This changed "useradd" command behavior which now defaults to creating the primary group with the same name as user and that was what I used. Which means inconsistent behavior between different tools, but that is not related to VB.
On 12/31/21 08:44, Andrei Borzenkov wrote:
You are right, YaST still defaults to assigning "users" as the primary user group. This changed "useradd" command behavior which now defaults to creating the primary group with the same name as user and that was what I used.
Which means inconsistent behavior between different tools, but that is not related to VB.
Andrei, At least VB can now (as soon as the new version propagates through OBS) handle both cases. I was just surprised that YaST used a different method than useradd. Larry
Larry Finger wrote:
I was just surprised that YaST used a different method than useradd.
Yes, I also find this to be a weird anomaly. It looks like there is some activity here to make YaST respect the /etc/default/useradd parameters, but it looks like it has stalled: https://bugzilla.opensuse.org/show_bug.cgi?id=1166743
Did TW changed to default to USERGROUPS_ENAB by default now or was this a config change you made? I have seen anything about the default changing....
On 1/2/22 18:44, Joe Salmeri wrote:
Did TW changed to default to USERGROUPS_ENAB by default now or was this a config change you made?
I have seen anything about the default changing....
It is now sort of the default in TW. When the installer creates a user, that will be the case, i.e. the userid:group will be username:username. for the moment, creating a new user using YaST will result in username:users - the old way. Larry
Hi Larry, You are right. I did a TW update over the weekend my system now has that as the default. I went ahead and creating groups for my existing users to follow the new standard. Where is the best place to learn about changes like this? I follow this mailing list and also Dominique's TW week in review but didn't see this mentioned anywhere ( or I missed it ??? ) Thanks Joe
On 1/5/22 22:30, Joe Salmeri wrote:
You are right. I did a TW update over the weekend my system now has that as the default. I went ahead and creating groups for my existing users to follow the new standard.
Where is the best place to learn about changes like this?
I follow this mailing list and also Dominique's TW week in review but didn't see this mentioned anywhere ( or I missed it ??? )
Joe, I did not see that change described in the week in review. I learned about it when boo#1194065 was filed. I discovered why guest graphics were failing when the original post in the thread was received. With the latest update of VirtualBox, the code does not care which standard is being followed, at least if you use X11. Wayland still has some problems that I am working to fix. Larry
Am 06.01.22 um 17:19 schrieb Larry Finger:
On 1/5/22 22:30, Joe Salmeri wrote:
I follow this mailing list and also Dominique's TW week in review but didn't see this mentioned anywhere ( or I missed it ??? )
Joe,
I did not see that change described in the week in review. I learned about it when boo#1194065 was filed. I discovered why guest graphics were failing when the original post in the thread was received.
Not sure if it was mentioned in the review, but there was a discussion on this list ([1], Message-ID: <20210805071845.GA8723@suse.de>). Aaron [1] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/Q...
participants (5)
-
Aaron Puchert -
Andrei Borzenkov -
Joe Salmeri -
Larry Finger -
S. B.