About Archive Tags RSS Feed


Entries tagged gnu screen

With many a winding turn

25 September 2007 21:50

GNU Screen rocks, in general, but recently I've been using it a lot for custom applications and have discovered a pair of annoying bugs.

If you're not familiar with it then please read this GNU Screen tutorial - it really is worth getting to know!

Anyway onto the bugs:

  • Session names may not start with numbers.
  • Session names must be globally unique.

The two are related, but I'm not yet sure whether I should report bugs against the Debian package and the code is sufficiently cryptic that I cannot create a fix yet.

Taking the bugs in reverse order please try this:

screen -S foo
screen -S foo2

At this point you should have two screen sessions "foo" and "foo2". You should be able to attach to them by running "screen -R foo" or "screen -R foo2". Lets try that:

skx@vain:~$ screen -R foo
There are several suitable screens on:
        22317.foo       (Detached)
        22342.foo2      (Detached)
Type "screen [-d] -r [pid.]tty.host" to resume one of them.

Even though foo should be sufficient to identify a unique screen, the first one, it doesn't let you attach. Nasty.

(Yes, you can attach to it if you use the number/number+name:

screen -R  22317.foo 

The second issue is related. Create a screen session with "screen -S 222". Now try to attach to it with "screen -R 222" - instead of attaching it gives you a brand new screen.


| No comments


She couldn't quite explain it

15 October 2007 21:50

Previously I wrote about two "bugs" with GNU Screen.

Now I discover, via a customer, that one of the servers I setup had allowed shell access when it should have been prohibited. A potentially serious security hole in this context.

Here is an example, with this small .screenrc file:

#  Normally "ctrl-a c" would open a new "window".
#  We wish to prohibit that
bind c

Start GNU screen. Press "Ctrl-a c" nothing happens. All looks well, you've denied a new window! If you'd setup a shell in /etc/passwd to point to a wrapper which invoked GNU Screen with this configuration file you'd be fine, right?

Actually not. Try pressing "Ctrl-a" and whilst those two keys are held down press and release "c". Joy. New window created. Even though it shouldn't be.

Update - Turns out I'm stupid "ctrl-a c" is the same as "ctrl-a ctrl-c" by default. I didn't add "bind ^c" appropriately. My bad.

For reference if you want to stop shell creation and you invoke screen as a login shell as a wrapper for other things then you must unbind a lot of builtins. eg. "bind :". You should then set:

shell /bin/false

Only then will you be secure. Probably.

Thankfully this doesn't affect the Xen shell.

| No comments


You see I'm falling in the vast abyss

24 October 2007 21:50

A while back I posted about a couple of my irritations with GNU Screen.

One of my irritations was the failure to reattach to sessions by name, if common prefixes were in use. For example with the following two (detached) sessions:

There are screens on:
        24419.abc       (Detached)
        24395.abcd      (Detached)
2 Sockets in /var/run/screen/S-skx.

The naive "screen -R abc" fails.

Yesterday whilst looking over the screen bug list I came up with a patch. It isn't ideal as it introduces a new failure case, but I believe it is a step in the right direction and better than the current situation. See attachment to #361274 for the code.

Also I patched screen so that #330036 is now fixed, and the blankerprg primitive works as expected.

Finally I closed #317450 (with a version) as it has been fixed since Etch.

Fun stuff.

In the spirit of completeness I should say I had a stab at #447210 which is tilde (~) expansion in the chdir primitive, but gave up after a while as the code got too messy even for me.

The trivial s/~/getenv("HOME")/ approach works fine for the simple case, but dealing with the expansion of strings such as ~foo/bar/ gets messy quickly. I can offer my patch if there is any interest though as a stop-gap measure.

Now I'm almost tempted to look over another package's bugs, but I think I'd rather eat pie & drink beer...

must. stop. talking. about. pies.

Update: Patch for tilde expansion submitted to #447210 - tested and seemed to cover all cases. Now time for beer!

| No comments


When I was your age, television was called books

8 July 2008 21:50

There are few programs I use with so much combined love & loathing than GNU screen.

Yesterday I spent a while adding another feature I've been wanting for so long, the unbindall primitive.

In many cases I find myself using screen as a wrapper around other things. But usually I end up having to disable dangerous keybindings, to gain security or to protect users from themselves.

Typically this leads to a screenrc file looking like this:

#  Disable these bindings.
bind :
bind s
bind S
bind Z
bind ^\
bind c
bind ^c
bind z
bind Z
bind B

Instead it would be better if I could just say:

#  Unbind *all* keystrokes

#  Restore actions we need/want/love.
bind x quit
bind d detach
bind c screen

Anyway, thanks to a small patch I can now.

ObQuote: The Princess Bride



Dirty. Dangerous. Your kind of people.

16 October 2008 21:50

Screen Fork?

There are times when I think of forking. Mostly sanity returns very quickly, though

Still GNU Screen is one program that I use almost constantly, and it seems to work at a glacial pace.

The Debian package has a lot of open bugs against it. Some trivial, some annoying, and some with patches.

Making the program GNU/Linux only would simplify a lot of things. But then again would that be a legitimate reason to fork it?

Me? I'd just like to see some additional primitives.


I've come up with a nice simple qpsmtpd plugin to do spamgourmet-like setup.

This means I can have email addresses:

Plugin code will be in the usual place in the next day or two..

ObFilm: xXx



Take a portable terminal, go out there and patch in manually.

18 October 2008 21:50

I might regret this later, but until I recant:

This features several changes already, and a few more are pending.

ObFilm: Aliens