myDSL Extensions (deprecated) :: Screen extension



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?
chmod 666 /dev/tty1 works.
It's still not ideal, but I'm making progress.
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)
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
Quote
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...

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.
Next Page...
original here.