Tiny Core Extensions > TCE Bugs

GNU screen tty permissions / at least microcore?

(1/2) > >>

lucky13:
I haven't had time to sort through this but I was going to set up MicroCore-current (as a quick temporary server) last week and installed the GNU screen extension so I'd be able to multitask. Running as user tc, I was unable to use the tty; I was able to run screen as root. I only had a chance to boot again off USB without networking to look at the permissions of /dev/tty* and, aside from mixed permissions, didn't notice anything that leapt out at me. I haven't checked the extension under TC to see if there's a similar problem.

Has anyone already gone through this and sorted it out? I'll see if I can look more closely this weekend.

maro:
I've run into the same issue that trying to start 'screen' as user 'tc' and receiving a Cannot open your terminal '/dev/tty1' - please check. error message. I don't know the proper solution, but a work-around: Just logout of the current shell, and login again (as user 'tc'). The new login shell should allow you to use 'screen'.

My hunch is that due to the way that this initial login shell gets started (AFAIK via entry tty1::respawn:/sbin/rungetty tty1 --autologin root, in '/etc/inittab', and then via command exec su - "$TCUSER" in '/root/.profile'). My assumption is that '/dev/tty1' is still seen as being "owned" by root. Alternatively booting with boot code 'noautologin' (and then a login as user 'tc') is another way to avoid this problem.

lucky13:
I haven't updated/used TC in some time on my Aspire One but I compiled screen on it and it worked correctly the way I have it set up -- which is admittedly not the standard TC way due to some of the things I was doing with it before (emacs+livetex and a lot of stuff I was recompiling frequently for work when I was still using the AA1 for that). Screenshots and details:
http://lucky13linux.wordpress.com/2010/03/27/tinycoremicrocore-tty-and-gnu-screen-fun/

I used --disable-socket-dir during configure. No problems.

Also, I noticed /etc/inittab showed autologin to user name (from user cheatcode) rather than root. Perhaps that, too, resulted in proper execution. Not sure if inittab or /dev/tty* has changed since 2.2. I might have more time tomorrow to make a proper package and see if I can get it working right without logging out and back in or anything else.

lucky13:
My own extension worked fine in Tiny Core, but failed like the one from the repository in Micro Core. This is because of the default permissions and modes of /dev/tty1 in Micro Core. This could be "fixed" in several different ways, the easiest being the way ttys are set up by default (inittab, etc.). Personally, I'd like to see a separate group (not staff) set up for ttys. I don't want to beat a dead horse with my same old argument against promiscuous abuse of "sudo su" but it applies to setting permissions so everything belongs to group staff; these things should be more fine-tuned, not all lumped together. That's a subject for another thread, though.

Here's another solution that doesn't require logging out and back in, etc., as maro suggested.

Make sure /dev/tty1's ownership is set to root.staff (sudo chown root.staff /dev/tty1) instead of root.root (user= and tc are in group staff). Then make sure the mode is set to g+rw (sudo chmod g+rw /dev/tty1) so anyone in group staff can read-write screen's use of /dev/tty1. This can be set up on the fly as-needed or set up from bootlocal.sh, another script, etc. I won't vouch for any potential security issues (screen has had a few of its own). Just make sure you don't set world read-write. I suppose you could also set the ownership to $USER and permissions to only u+rw as well.

http://lucky13linux.wordpress.com/2010/04/01/micro-core-and-gnu-screen-fix/

maro:
lucky13: Quite an interesting investigation you've done. It has certainly opened my eyes and I'd like to expand just a bit on your findings and recommendation.

The MC 2.10 initrd contains '/dev/tty0' to '/dev/tty7' with ownership 'root:root' and permission '0666'. On a freshly booted "plain" MC 2.10 system there are '/dev/tty0' to '/dev/tty63'. All but '/dev/tty1' with ownership 'root:staff' and permission '0620'. I guess this is due to the KERNEL=="tty[0-9]*", GROUP="staff", MODE="0620" entry in '/etc/udev/rules.d/50-udev-default.rules'. The '/dev/tty1' device appears with ownership 'root:root' and permission '0600'. If one does logout and login again (as user 'tc') the ownership of '/dev/tty1' changes to 'tc:staff'.

I believe there is an alternative way to overcome the issue of ownership of '/dev/tty1'. I simply inserted chown "$TCUSER:staff" /dev/tty1 just before the exec su - "$TCUSER" in '/root/.profile'. After re-mastering the initrd, a test showed that this tweak appears to have done the trick (and 'screen' was working straight way).

The advantage that I see with this approach is that the ownership is changed from 'root' to $TCUSER at the last possible moment, and not done via a parallel process (like '/opt/bootlocal.sh'). The ownership is then also the same as after a logout/login sequence.

IMHO the question of a separate group for those '/dev/tty*' devices is something else to be considered by the core team. I'm not sure that we would gain much in terms of security considering that hardly any groups are in use in MC/TC and this would then raise the question to introduce a lot of different groups for different functionality.

Navigation

[0] Message Index

[#] Next page