Screen extension

Forum: myDSL Extensions (deprecated)
Topic: Screen extension
started by: mikshaw

Posted by mikshaw on Jan. 07 2005,23:07

I haven't figured out why a regular user cannot open tty from screen. Using setuid and setgid doesn't help, but sudo /opt/screen/bin/screen does work. This is promising, but not ideal...i don't want to have to be root when running it.

I noticed while exploring the filesystem that there are at least a couple of references to Screen in DSL. /etc/terminfo/s/ contains files for Screen, and /etc/pam.d (i think) has a screen file.

There must be something in DSL which will allow me to change permissions on tty*, but I'm afraid that whatever it is would not be acceptable for use in an extension. Still going to look around more.

Another thing that needs to be addressed is a password. I accidentally locked screen and it kept asking for a password, even though I had never set one. I had to reboot in order to get out of it.
I know I always say there's hardly ever a need to reboot, but I don't understand screen well enough to know how to close it when it's locked. This is one situation where having virtual terminals would be very useful....which reminds me....why doesn't DSL have them? Does this feature actually add anything to the size of the distro?

Posted by mikshaw on Jan. 08 2005,01:54

chmod 666 /dev/tty1 works.
It's still not ideal, but I'm making progress.

Posted by mikshaw on Jan. 08 2005,04:03

Still no luck making the thing run as user dsl without changing owner or permissions of /dev/tty1.

It's completely useable as is, though. If you can't load a gui and boot with 'dsl 2' then you're running as root anyway...screen is a handy way to use multiple terminals in this situation.

So....whatta ya think....should this be submitted as an extension at this point, or should I continue looking for a secure way to run it in tty as dsl? Keep in mind that it will run as dsl in rxvt.

EDIT: While researching screen I discovered a text(curses)-based window manager called twin. It will work in the linux console as well as in X(with a textured gui rather than curses), although there are some annoyances when running in DSL.
It tries to use mouse in Linux terminal, even though it's not supported there, so you have to hit Enter a couple of times past their error message before it starts up.
In X, it only takes up a portion of the screen...I think it's set at a 640x480 resolution, which is rather annoying.
Configuration is rather difficult to understand....I attempted to change the menu key to something else, going by their examples, and it broke. I had to do a hard reboot to get out of it. I think they need to reconsider the way they use hotkeys...maybe have a 'quit' hotkey built into the program instead of relying on a menu item (similar to the way X uses Ctrl+Alt+Backspace in case nothing else works).
Otherwise it's a pretty cool thing for windowing without an X environment. I'll keep playing with it, and if I can get it to be a little less of a pain for key mashers I'll make it into an extension ('key mashers' in this case would be people like me who, when all else fails, start pressing random key combinations hoping something will work)

Posted by ke4nt1 on Jan. 08 2005,04:27

If it will run from a shell, make a small wrapper..
Look at the start_gimp or start_gtk2 wrappers for examples..

You can execute the application from a shell within the wrapper..
And many of the apps , especially ones requiring port access,
use root to run.. setuid isn't much more secure anyway...

I have a few wrappers for other extensions that run apps as root as well.
NmapFE needs root access ... RKHunter also..
But their designed as apps to be run as root user tools.

Does your suse version run it as setuid/root ?
Could we use alien to convert the rpm to deb for that version ?
( which doesn't use the elf lib.. )

73
ke4nt

Posted by mikshaw on Jan. 08 2005,04:59

Quote

The thing I'm most concerned about is that Screen isn't merely an application running within a shell...it's comparable to a window manager which launches other shells and applications within it. I don't know how much of a risk this is, but it wasn't long ago that Screen was found to pose a security risk in certain situations when run as root, so most packages now don't install it with setuid. I'm using suse 9.0, which is a couple of years old, and screen is not setuid here.

Quote

Could we use alien to convert the rpm to deb for that version ?

That wouldn't fix the trouble I'm having. First it would require mkwriteable, which I'm trying to avoid like JWs, and second it doesn't do anything to open up tty1 to users.

I still don't understand the tty permissions. /dev/tty1 is owned by root.root, with 600 permission. I thought that would mean that a regular user couldn't access it at all, but dsl still uses it as the primary terminal. In my Suse system /dev/tty1 is owned by mik.tty, with 620 permissions. 'mik' is my typical user....I have no idea why the file is owned by me, unless Suse has some script which changes ownership depending on who is logged in. But that still doesn't make sense, because there is only one /dev/tty1...what happens when multiple users are logged in at the same time? I think it might have more to do with the group 'tty' than with the owner, but this is just a guess.

Posted by ke4nt1 on Jan. 08 2005,05:26

I wonder if that is a leftover from the symlink to /KNOPPIX/dev..

I mean, it HAD no choice but to be read only at one time..
When it was a liveCD, there was only a symlink from /dev/tty1
to /KNOPPIX/dev/tty1, which HAD TO BE read only on the cd.

I know that when using the serial port, /dev/ttyS0, with one of my
ham radio devices ( a TNC ) , I had to change permissions on the device,
after making that portion of the filesystem writable thru mkwritable.
( installing a .dsl extension, like dsl-dpkg.dsl, easily does it. )

Installing to Hard Drive may not, by default, be changing the
device to be writable to ANY users .. your SuSE wouldn't have that issue,
having never been in a read-only format during its operational lifetime.

And there have been many posts of late where the serial devices are not
communicating either..

It appears that DSL uses tty0 for its main terminal, not tty1
This is some output of ls -al tty* > /home/dsl/tty.txt

crw-rw-rw- 1 root root 5, 0 Jan 7 23:00 tty
lrwxrwxrwx 1 root root 7 May 17 2004 tty0 -> console
crw------- 1 root root 4, 1 Jan 7 22:17 tty1
crw------- 1 root root 4, 10 Sep 11 1998 tty10
crw------- 1 root root 4, 11 Sep 11 1998 tty11
crw------- 1 root root 4, 12 Sep 11 1998 tty12

Does this change when installed to HD?
What is your output ?

73
ke4nt

Posted by mikshaw on Jan. 08 2005,06:15

but....I don't have a harddrive install. I'm trying to build this to be completely useable in a liveCD without mkwriteable.

One thing I noticed yesterday that never even began to think about the possibility of considering coming to my attention before is that there are more writeable directories in a DSL livecd than I had thought. /etc is writeable to a point...you apparently can't overwrite the symlinks without first deleting them, but you can add files. In /dev many of the devices can be edited, which is why I was able to change permissions on /dev/tty1. All this time I thought /opt, /var(/tmp?) and /home were the only writeable directories without running /etc/init.d/mkwriteable. So /var and /etc aren't symlinks, but actual directories in ramspace. It's kinda confusing since the others are located in /ramdisk....makes my brain hurt.

Another odd thing is /dev/tty2 (and one or two others...can't remember which ones) is owned by dsl.staff. I understand tty2 is where X is run in debian systems, and in suse it's tty7 (owned by mik.users.../dev/tty1 is owned by mik.tty). /dev/tty8 is owned by another regular user, which i tend to use occasionally in a sub-shell. What I don't understand is WHY and HOW the ownership is changed...is it done when the user logs in, or is it maybe something that should not have happened? When I log in as root with root environment, it still shows the same ownerships, so maybe it's a first-come-first-served ownership thing....i dunno....some things about Linux make my head spin.

Quote

It appears that DSL uses tty0 for its main terminal, not tty1

When I exit X and type 'tty' it shows /dev/tty1

Posted by mikshaw on Jan. 09 2005,01:14

STILL no luck getting it to run as user dsl without manually changing ownership of tty1. I think this is either DSL being stubborn or the setuid bit not working.

I zipped it up anyway...seems like there's nothing more I can do. It can be run in an X terminal without problem. Running from console requires either 1) running it as root, or 2) executing 'sudo chown dsl.staff /dev/tty1' before running it as dsl. Chmod'ing is probably a bad idea since it opens the session to reading from anyone.

Another thing is the utf8 encodings....I don't know how necessary they are. Screen works without them in a vanilla DSL, but I wonder about custom systems. I'm leaning toward leaving them out...the compressed archive is 153k without them, opposed to 390k.

Posted by cbagger01 on Jan. 10 2005,04:32

Be carefull with adding stuff to the other writable areas of a DSL livecd bootup.

If the directory is not symlinked into /ramdisk, then it is part of the root "/" filesystem and there is a very limited amount of free space in this filesystem.

For example, type:

df

and see what the available space is.

Posted by mikshaw on Jan. 10 2005,04:42

not sure what you mean by "adding stuff". I don't think chown adds anything to the file size.

Posted by cbagger01 on Jan. 10 2005,05:49

What I mean is:

If you are adding files to:

/
/etc
/root

these directories are part of the root filesystem and are not stored in the /ramdisk

The root filesystem has a limited amount of available space.

So if you put too much stuff inside /etc, then you will run out of space in your root filesystem.

Small text configuration files are fine, but if you are trying to add applications to /etc in an effort to avoid running mkwritable then "bad things" can happen.

Posted by mikshaw on Jan. 10 2005,05:55

OH!...I see what you're saying. I forgot that I had mentioned /etc being writeable.

I suppose that's mainly just so you can make some edits to existing files if necessary.