When using startx to start x, owner of /dev/vc/0 is changed to <user>:users. This isn't even restored when quitting X! This is even preserved across reboots!! (actually, this also happens when starting via xdm, only diff being X is started as root so no one will notice) Steps to reproduce: 1. log into vc2 as root (not strictly required to reproduce; but to have a place to check things safe from pam_console messing with perms) 2. make sure permissions are as follows: #ls -l /dev/vc/[0-2] crw------- 1 root root 4, 0 Jan 1 1970 /dev/vc/0 crw------- 1 root root 4, 0 Aug 14 15:04 /dev/vc/1 crw------- 1 root tty 4, 0 Aug 14 15:04 /dev/vc/2 3. log into vc1 as normal user 4. check perms #ls -l /dev/vc/[0-2] crw------- 1 root root 4, 0 Jan 1 1970 /dev/vc/0 crw------- 1 hww tty 4, 0 Aug 14 15:05 /dev/vc/1 crw------- 1 root tty 4, 0 Aug 14 15:05 /dev/vc/2 5. startx from vc1 6. ls again #ls -l /dev/vc/[0-2] crw------- 1 hww users 4, 0 Jan 1 1970 /dev/vc/0 crw------- 1 hww tty 4, 0 Aug 14 15:05 /dev/vc/1 crw------- 1 root tty 4, 0 Aug 14 15:05 /dev/vc/2 7. quit X session 8. log out on vc1, reboot, do whatever you want; /dev/vc/0 will be owned by the user who last started X until someone else starts X. (as does vc/7, although this is probably less critical) Reproducible: Always Expected Results: Permissions on vc/0 are left alone. (can't see a reason to change them; X doesn't even use it) (not sure yet if this is just a cosmetic thing or more critical, so I'm leaving severity at "normal". feel free to adjust)
Changing severity to critical. underlying problem here seems to be pam related.
This is not a 4.3.0 exclusive problem it still appears in the 4.3.99 branch, it appears one of the libraries takes ownership but I havent found why just yet...
Created attachment 21531 [details, diff] Patch to fix This patch is based against the 4.3.99.16 snapshot. It appears that XFree chown the consoles when opening the console but do not remember or restore the console ownership, this patch adds this functionality.
Extra, patch cleaning applies against 4.3.0 aswell
Thanks!!! works perfectly.
Unfortunately, it's not that easy... ;) If a user wants to own `tty0', they can still start two instances of X and purposely terminate them not in reversed order...or just SIG_KILL the first instance. Question should rather be, as it already says in the source, "Why is this[changing tty0 ownership] needed?"
The support for tty0 in the patch is hard coded just like in the source. I fully intend to remove it if possible. But at the moment the restoration of the consoles works with this patch. I do not understand your comment about it not being that easy, can you please clarify what you meant?
What I meant is, with this patch there are still two or more ways for an ordinary user, intentionally or unintentionally, to gain ownership of `tty0'. [the following assumes that X1 is started by user1 and X2 is started by user2, which may or may not be the same user] (1) - as root, chown root:root tty0 - start `X :1' as user1 ("X1") (tty0 is chown'd `user1:users') - start `X :2' as user2 ("X2") (tty0 now belongs to `user2:users') - Ctrl-Alt-Backspace out of X1 (X1 restores permissions to `root:root') - Ctrl-Alt-Backspace out of X2 (X2 restores permissions to what it found when it was started--`user1:users') (2) - as root, chown root:root tty0 - start X1 as user1 - kill X1 (owner of tty0 will be `user1:users') Or, the equivalent real-life scenarios, (1) - user1 locks their display and leaves - user2 logs in and starts a second X session - user1 and user2 may quit X in any order (2) - power failure / X has to be killed / (X crashes) / ... The problems I see here is that a process should not make changes to to objects if it is not guaranteed these changes are reversed at termination. If two invokations of the same program may make different changes to the same object there's definitely a problem. If those changes are made from a suid root program, that's a big NO-NO, so it's definitely worth investigating why the second chmod call is needed in the first place. [Don't quote me on that yet, but from looking at the source, at least for the linux server on ix86 hardware it's *not* needed. Sorry for commenting here without a better solution, just wanted to point out there are ways around this patch]
This solution was just committed to xfree cvs, so if you have a better one, post it to there. =) http://bugs.xfree86.org/show_bug.cgi?id=927
Unfortunately (again!)... until you find a way to catch SIG_KILL, there *will be* no solution to this problem...which is why I made it a policy to install the X binary `u-s' (and `o-rx', to avoid confusion) at least on publically accessible machines. [I'll look into if tty0 really needs to be chmod'ed at all if I find the time...although that may take some time]
[err...s/chmod/chown/]
Ive done some very loose testing to see what happens if tty0 is not chown'ed and so far it looks like everything works normally... Combining this and the logic from bartons' comments, about two X sessions changing the owner possibly I cant see the need for the current user to own tty0. Ive popped off an email the the xfree ml to see what people say.. But hopefully this can be resolved soon.
I think the second chown (`tty0') goes back to a patch in the linux port of X11R5/X386 to allow xconsole to read from `/dev/console' (in the days of 0.99 and early 1.x kernels, `/dev/console' used to be a symlink to `/dev/tty0'. These days xconsole is usually configured to read from `/dev/xconsole'). Still trying to find that patch though... if I remember correctly there was also a comment why vt7+ is chown'd...
Ive been running 4.3.0 and 4.3.99 now for a few hours both without ownership on tty0 and have noticed nothing odd in startup or in the logs. I cannot find a satisfactory reason for this ownership to still occur, nor did anyone in the ML have a reason...! Should we just drop it? Comments anyone? Or your own test results...
Commenting to remind myself/spyderous to remove the vt0 chowns' for the next releases of both 4.3.0 and 4.3.99.902...
The only time that permissions are not saved on X exit is for a sigKILL as far as I can see. Which makes sense as the server doesnt shutdown. However I have also noticed that udev actually resets the right permissions on the devices at reboot. Not recommending people use udev, but Im not so sure how to detect a sigKILL and act on it... thats the idea i thought. What Im recommending is that we have the chowns setup properly, on startup and proper shutdown of the server and just leave the rest to udev when it gets marked stable... Might be a kludge but unless someone knows how to detect sigKILL
man signal
Erm, Reading straight from man signal "The signals SIGKILL and SIGSTOP cannot be caught or ignored." The only way around this i can see would be to create a futher wrapper similar to xinit and let it have total control over terminal permissions, setting them and then unsetting them on exit of the XServer, this process would have to not be the Xserver but some other process that would not attract attention
do any progs specificly require access to that devices? if x11 is started form a display manager uid and euid are 0 and tty0 and tty7 are left root.root anyway; and i didnt eventhink of situations like in comment #8 when opening this bug. our admins have set up a custom x11 ebuild in the meantime which leves /dev/tty0 dev/tty7+ and /dev/console alone (nothing personal but current x11 ebuilds cause major portability issues; x progs compiled on gentoo x11 dont run enywhere else) and we havent seen seen problems as of yet w/ that permissions. xconsole should be handeled debian style per /dev/xconsole only (after a proper fix to devfsd.conf so /dev/xconsole is properly recreated after reboots)
Could you elaborate on exact problems for "progs compiled on gentoo x11 dont run enywhere else"?
of course (1) libs who are only available as static libs on other dists are shared libs on gentoo; if the development box is running gentoo, progs built on gentoo abort with "error while loading shared libraries: libXXX.so.n: cannot open shared object file: No such file or directory" running on other distros. in the other direction (2) a very expensive package looks for x11 core fonts in x11's font directory if x11 is installed (seems reasonable); "Font file ZZZ not found, please make sure all required X11 font packages are installed." font is there; but not where it is expected. (symlink helped; moving fonts back to standard dir too) (3) in last tested ebuild Xresources are still ignored if x is started from xdm gentoo on gentoo (4) xcursors are too well hidden where no other prog will find them (for example, kde control center; moving back to standard dir helped)
I assume (2) is for 4.3.0-r6 and/or xorg-x11. I plan to add some backwards compatibility symlinks for a little while to deprecate the old locations before they are obsoleted, but I haven't yet. ~arch is good for finding some problems like this. As for (1), there are very few we should be producing shared that most other distributions do not. All of the non-standard shared libs I'm aware of are required for Loki's games, and at least one other distribution produces the same set. I believe you've got a bug filed for (3) and work is in progress on that. Does a symlink work around (4)?
as for (1), in all fairness i'm somewhat glad im not in your shoes; from an end-users perspective its always beneficial if all shared libs that could possibly be needed are provided. but on a development box, the case is quite the opposite: you only want shared libs GUARANTEED to be available on ALL targets. in addition to comment #21 (5) xinit still defaults to xvt, a prog abandoned 12 years ago, as its default client, what isnt even listet as a dependency, brought in by xfree AND xorg(!) patchesets. another other-distributionism that has to die-die-die! cuz it requires special treatment of gentoo in site-wide startup scripts.
sorry Andrew, got a bit carried a way by donny's question; but as i see it a wrapper that can modify files in /dev will have to be a suid prog that can just as easyly be killed as X itself if started by a normal user as in startx, leaving behind files belonging to a normal user who maybe not even logged in any more
The devices arent chowned when using a display manager because the display manager is run as root; ergo they chown to root:root ... I do not know if there is any point to the devices changing owners, I actually think its reminiscent of old X versions... im emailing the xorg list to see what poeple know there Unfortunately i cant test for a few days..
Well, what's the progress here?
Well the patch attached here is in xorgs release. My only remaining suggestion to prevent the persistant ownerships from server crash is to have a sort of "getty" service started in /etc/inittab similar to normal system gettys, this would ensure root:root except when in use by X as a normal user. Also it would allow some better vt control on the X startup.. Actually inittab might not be the best place but something similar.
I'm confused, I thought that patch was in xfree already in December 2003; before xorg forked (if I understand http://bugs.xfree86.org/show_bug.cgi?id=927 correctly). Remaining questions are: 1. What if there is more than one X-session running on the same box, each belonging to a different user? Who should own vc/0 then? 2. Why is this still needed? You said it is from old versions of X; now what *did* people on the xorg list say? 3. Same problem happens to /dev/console when using xdm/kdm. Can't use it right now because some programs still don't work when running in a DM session; but once they do, what's gentoo's policy on /dev/console? Being able to start an additional DM session as a different user (from K-menu, f.ex.) is pretty much standard these days. Z. Don't understand the rest of comment #27.
Created attachment 61188 [details, diff] New Patch This patch completely disables the permission changing, X is still running perfectly here after compiling with the patch applied. This wont work if X does not run suid, however thats a different problem.
This bug should be filed upstream, where it can get some more action. Could someone please file it at bugs.freedesktop.org, xorg product, and post the URL here? Thanks!
