GNU screen tty permissions / at least microcore?

[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.

[lucky13]

For the record, I was still looking at TC/MC 2.2 as those were the last updates I did on my Aspire One and I didn't have my USB stick with me today (I'm not inclined to update since I rarely even boot into Linux on it anymore and only use wifi when I have my USB adapter due to ath5k+WPA timeout issues; this all arose on another computer). I was looking for the simplest possible solution which could be handled at boot and through reboot without remastering or setting up tweaked files via filetool, etc.

I think I like your approach even though I think I'd prefer to leave ownership to root(.staff) rather than user. Or a separate tty group, as some (not all) distros do. I realize the possible gains in security are negated by wide-open default sudo privileges, which is one of the concessions which is necessary for a nomadic environment. Nearly everything is owned by user tc and/or group staff and tc can sudo everything without a password to do anything tc.staff can't do.

In any event, perhaps Robert and Co will either edit /root/.profile as you did or edit udev rules accordingly/appropriately.

PS: Added props to maro on my blog entry (last link: microcore and gnu screen fix).

[roberts]

/root/.profile has been changed dropping exec su - "$TCUSER" to using exec /bin/login "$TCUSER" instead, suggested by ^thehatsrule^

Code: [Select]

#!/bin/sh
NOAUTOLOGIN=/etc/sysconfig/noautologin
if [ -f "$NOAUTOLOGIN" ]; then
 if [ -s "$NOAUTOLOGIN" ]; then
   > "$NOAUTOLOGIN"
   exit
 fi
else
 if [ ! -f /etc/sysconfig/superuser ]; then
  TCUSER="$(cat /etc/sysconfig/tcuser)"
  exec /bin/login "$TCUSER"
 fi
fi


[curaga]

Is that a double test for the same thing?

if [ -f "$NOAUTOLOGIN" ]; then
 if [ -s "$NOAUTOLOGIN" ]; then

-s FILE        True if file exists and is not empty.

Or is there a way for it to exist but be empty?

[alandoland]

When you download a file using google chrome, a representation of it appears in the bottom status bar. Normally you would be able to click on it to launch the file, or use the arrow to "Show in Folder". On TC, those don't work, and I'm coming to realize how important those features are to normal workflow.

[lucky13]

When you download a file using google chrome, a representation of it appears in the bottom status bar. Normally you would be able to click on it to launch the file, or use the arrow to "Show in Folder". On TC, those don't work, and I'm coming to realize how important those features are to normal workflow.

What does that have to do with the GNU screen extension and/or tty permissions? You may want to repost to another area or separately, but that's off-topic.