trusty X server display malfunctions when uid != 1000

[parke]

I have been using Crouton with trusty and Openbox (via the lxde target) on an Asus Chromebox for a little over a month. Yesterday I rebooted, which caused Chrome OS to upgrade itself. Following upgrade, inside trusty the X server display started malfunctioning.

Specifically: Initially, most of the screen is black, the exception being the LXPanel at the bottom.  The screen only refreshes due to user activity, and even then, only partially refreshes.  Consequently, the screen is usually displaying stale and/or corrupted windows.

Interestingly, the problem only manifests when running as a user other than 1000.

Steps to reproduce the problem:

# Create a trusty chroot named vanilla.
$ sudo sh -e ~/Downloads/crouton -t lxde -n vanilla -r trusty
$ sudo startlxde -n vanilla
# X display functions properly.

# Then create another user named u1100.
$ sudo enter-chroot -n vanilla
$ sudo groupadd -g 1100 g1100
$ sudo useradd -g g1100 -m -s /bin/bash -u 1100 u1100
$ exit

# Enter LXDE as user u1100.
$ sudo startlxde -n vanilla -u u1100
# The X display malfunctions, as described above.

Ancillary issues:

1. In LXDE, the Logout option does nothing. In precise it works, but not in trusty. Logging out requires switching to Chrome OS, and pressing ^C in the terminal to kill X. (Aside: this does not really affect me, as I typically use a custom ~/.xsession file.)

2. During the creation of the vanilla chroot, my keyboard layout in Chrome OS was reset from Dvorak to Qwerty. The only way to correct was to log out of Chrome OS.

3. Simultaneous with the keyboard layout change, the responsive of my trackball dropped to almost nothing. As in: spin and spin and spin and spin to slowly, slowly move the mouse cursor across the screen. At this point, the Chrome OS settings page said that no mouse or touchpad was detected. Again, logging out of Chrome OS was required to fix the problem.

Chrome OS version info:
Version 35.0.1916.155
Platform 5712.88.0 (Official Build) stable-channel panther
Firmware Google_Panther.4920.24.22

crouton version info:
VERSION='1-20140421214646~master:b766b319'

An obvious workaround should be to only run Crouton as user 1000.

[drinkcat]

VERSION='1-20140421214646~master:b766b319'

1. In LXDE, the Logout option does nothing. In precise it works, but not in trusty. Logging out requires switching to Chrome OS, and pressing ^C in the terminal to kill X. (Aside: this does not really affect me, as I typically use a custom ~/.xsession file.)

Your crouton version is a bit old, and that specific issue was fixed in #859.

You should probably start by fetching the latest crouton installer and updating your chroot.

Then, regarding running crouton as user 1100, when we create user 1000 we add it to several groups (audio,video,sudo,plugdev). Can you add your user to these groups (at least video) and see if that fixes the problem? Your problem sounds like fbc issue, see #477, which requires the user to be in the video group for the fix to work.

[parke]

Yes, a newer version of crouton ( version 1-20140618114627~master:e43062bf ) does seem to fix the LXDE logout, mouse and keyboard layout issues.

Running sudo usermod -a -G video,sudo,plugdev,audio u1100 inside vanilla fixes the X server display problem for user 1100. Thanks!

Interestingly, inside my old chroot (named trusty), user 1100 already belonged to the necessary groups. I must have manually added them previously. Inside the old chroot, the problem was caused because my custom ~/.bashrc file reordered the PATH.

# PATH after enter-chroot
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

# PATH set by my custom ~/.bashrc file
/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

Due to my custom path, the wrong xinit was being run. And for some unknown reason, the problem only manifested after a Chrome OS update. Inside my old chroot, manually running /usr/local/bin/xinit .xsession fixes the problem.

Perhaps Crouton's /usr/local/bin/xinit could check to make sure that the user belongs to the necessary groups? This would have quickly identified the problem inside vanilla.

Another ancillary issue that I forgot to mention previously:

Because I run xinit as different users, X logs this error message.

/usr/local/bin/croutonxinitrc-wrapper: 72: /usr/local/bin/croutonxinitrc-wrapper: cannot create /tmp/crouton-lock/xbindkeys: Permission denied

Perhaps this should be created as a separate issue? I am not aware of any negative side effects.

[drinkcat]

Inside the old chroot, the problem was caused because my custom ~/.bashrc file reordered the PATH.

Yeah. A lot of things in crouton rely on /usr/local/bin precedence... Fixing that would be quite tricky (e.g. we use the stock startxfce4 script provided by XFCE, and it works only because it calls xinit without absolute path), so it's probably not going to happen.

Perhaps Crouton's /usr/local/bin/xinit could check to make sure that the user belongs to the necessary groups? This would have quickly identified the problem inside vanilla.

We could. Now, on each update, we add the necessary groups to user 1000. So you're a bit of a special case here...

Because I run xinit as different users, X logs this error message.

/usr/local/bin/croutonxinitrc-wrapper: 72: /usr/local/bin/croutonxinitrc-wrapper: cannot create /tmp/crouton-lock/xbindkeys: Permission denied

Yeah, crouton has not really been designed thinking about multi-user with different UID (or maybe it was originally and I broke it)... /tmp/crouton-lock is created with permissions 775 but if the 2 users don't share the same primary GID, that's not too useful...

Perhaps this should be created as a separate issue?

No, that's basically the same issue: we don't support UID != 1000 (you can rename the issue if you want, though).

I'll think about it, maybe by making sure all shared files are under GID 100 (users in Chrome OS), then we can map users in Chrome OS to crouton in chroots and check that the current user is part of the crouton group.

I am not aware of any negative side effects.

You will definitely run into problems if xbindkeys fails to start (if you close the first chroot the second xbindkeys will not start).

[parke]

Perhaps Crouton's /usr/local/bin/xinit could check to make sure that the user belongs to the necessary groups?

We could. Now, on each update, we add the necessary groups to user 1000. So you're a bit of a special case here...

I was just thinking of printing an error message and aborting if the group requirements were not satisfied. The alternative (as is done at present) is to launch an X session that will almost certainly be broken.

Yeah, crouton has not really been designed thinking about multi-user with different UID (or maybe it was originally and I broke it)...

$ enter-chroot --help
   -u USERNAME Username (or UID) to log into. Default: 1000 (the primary user)

Perhaps a note should be added to enter-chroot --help saying something like "UIDs other than 1000 may not be fully supported."

In my case, I did not want my Ubuntu processes to be able to send signals to chronos processes. And I wanted to be able to easily display only the Ubuntu processes in top.

/tmp/crouton-lock is created with permissions 775 but if the 2 users don't share the same primary GID, that's not too useful...

IMO, stale lock files should be removable. Alternatively, if /tmp/crouton-lock is not used as a lock, why not use /tmp/crouton-state-$USER.

You will definitely run into problems if xbindkeys fails to start (if you close the first chroot the second xbindkeys will not start).

But I may not be using xbindkeys for anything. I'm running on an Asus Chromebox, with a third party keyboard. The documented Chrome OS -> Crouton keyboard shortcuts have never worked for me. They seem to expect a standard Chromebook keyboard. As for Crouton -> Chrome OS, I just press Ctrl + Alt + F1.

[dnschneid]

I had intended to make crouton multi-user safe from the start, but more or less forgot about it as general integration and compatibility improved. We should definitely do a scrub and get things working well for multi-user scenarios again (and add a test for it).

[parke]

Another multi-user issue to be aware of is write access to ~/Downloads. Personally, I'd rather not have a shared ~/Downloads inside the chroot, but that is just me.

[dnschneid]

We should probably limit ~/Downloads bindmounting to just uid 1000, and possibly uid 0.

[dnschneid]

Actually, we should map group chronos-access to "crouton" inside the chroot, and start using that as the gid for our various lock files as well.

[smuehlst]

I did run into this issue when I created an additional user account within the chroot environment (Ubuntu Trusty with xfce), and then started the chroot environment with "sudo startxfce4 -u ".

My main goal is to have accounts with different home directories. I don't care whether the users share the same user id. Therefore I changed the user and group id for the additional user account to 1000/1000 in the /etc/passwd file of the chroot environment. The strange thing is that the problems persist, for example characters typed on the keyboard within the terminal application aren't echoed.

Are there any easy workarounds for the use case to have multiple home directories selectable by the "-u" option when starting the chroot environment with startxfce4?

[parke]

@smuehlst

Did you try this workaround?

#908 (comment)

I have not used XFCE, just Openbox.

[smuehlst]

@parke
The workaround from comment #908 helps, X seems to be ok now with the other users, thanks!

[dnschneid]

Hmm, chronos-access is gid=1001, which will mean the second user will have uid=1001,gid=1002...is that okay?

[dnschneid]

Maybe devbroker-access is a better idea.

Scratch that. chronos-access makes more sense.

[dnschneid]

Implemented in the multiuser branch.

[fczuardi]

What is the proper way to test that branch? Do I need to add the secondary user to any specific group? Do I need to clone the repo, switch to that branch, then do a ``Make` to generate crouton and then run this one with -u to update the chroot?

[dnschneid]

You can download a .tar.gz snapshot of the branch, extract it, then run installer/main.sh as if it were the crouton release binary. It's not completely up-to-date with master, so I recommend making a fresh chroot (and maybe even using a separate prefix with -p) when trying it out.

[fczuardi]

I will try that, thanks!

[dnschneid]

crouton now has the multiuser branch merged in. You do have to add the second user to the right groups, but it should work now.