Skip to content

Bring me everyone.

27th October 2008

Recently I've been hacking around on GNU screen. I've fixed a few bugs and added a few new features. One of the earliest features I added was the ability to source every file in a directory. One of the later additions was to add simple conditionals to the dotfile, via the new if primitive.

Today I had an epiphany moment. Rather than adding either of these two features I should have altered the behaviour in the far simpler manner.

If we allow ~/.tscreenrc to be an executable we immediately gain lots of things for free.

Consider this ~/.tscreenrc file:

#!/bin/sh

for i in ~/.tscreen/*; do
    if [ -e $i ];
       echo "source $i"
    fi
done

That gives us the effect of a "source directory/" primitive. Similarly I can do complex tests without the need for an if primitive if I were to write this:

#!/bin/sh

# common config
cat ~/.tscreenrc.common

# per host config?
file=~/.tscreenrc.$(hostname --fqdn)
if [ -e "$file" ]; then
   cat $file
fi

# if we have lynx define an alias for it + map it to a key
if [ -x /usr/bin/lynx ]; then
   cat <<EOF

# Surf the web with <Ctrl-a f>
alias web screen -F -t web /usr/bin/lynx
bind w web
EOF
fi

So as of v0.4.7 tscreen allows you to have your configuration file be:

A normal file:

In which case it is parsed as you'd expect.

An executable file:

In which case it is executed and the output is parsed.

The code change is trivial, just an extra stat call and the use of popen vs. fopen, but the payoff is significant.

ObFilm: Léon

Tags: tscreen. | 7 comments.

Comments On This Entry

  1. [gravitar] Joe Buck Submitted at 23:34:14 on 27 October 2008
    As a screen user, this proposed change makes me very nervous. An executable that the user can't see has the ability to do anything. You're using it to generate output, but it can do anything that the user has permission to do. And since the basic screen program, without customization, serves well enough for many users' purposes, all you're doing is introducing a new security risk so that a small minority of users can do fancy tweaks.
    I hope that there's a way for the system administrator to turn this feature off, globally, and that distros make this the default.

  2. [gravitar] Anonymous Submitted at 01:09:32 on 28 October 2008
    Wow, *nice*. More programs should do exactly that.
  3. [gravitar] Des Submitted at 01:46:25 on 28 October 2008
    Have you considered giving this executable file information about the screen instance with enviroment variables? A nice example I can think of is having $TSCREEN_SOCKET_NAME (with the content of the -S option argument), so one could do something like:
    #per session/socket stuff
file=~/.tscreenrc.$TSCREEN_SOCKET_NAME
if [ -e "$file" ]; then
   cat $file
fi
    or:
    if [ x$TSCREEN_SOCKET_NAME -eq xweb ]; then
  echo screen lynx http://google.com
  echo screen lynx http://slashdot.org
fi
    think of: 
    screen -S monitor (bwm-ng, iftop, top, vmstat, etc...)
screen -S irc
screen -S remote_shells (lots of sshs)
screen -S databases (mysql, pgsql, etc...)
etc...
  4. [author] Steve Kemp Submitted at 09:24:02 on 28 October 2008

    Joe: Whilst it is true that the script can do anything the user can it already is disabled by default.

    For this to start happening you need to explicitly change your ~/.tscreenrc file to be executable. By default this shouldn't be the case.

    Des: No I'd not considered that, but it does make sense.

    Anonymous: Yes, yes they should!

  5. [gravitar] Owen Synge Submitted at 22:32:34 on 28 October 2008
    Thank you Joe Buck for clearly expressing my opinion, I fear it is a security risk worth avoiding. I would support such a change if the scripting language you proposed was LUA embedded in screen.
    Fortunately I use screen less than I should, I would not allow screen on my systems unless you contained the scripting LUA seeming an obvious way. Some may create considerable state to their screen sessions, and may like the power without the security risk of your proposal.
  6. [author] Steve Kemp Submitted at 22:40:04 on 28 October 2008

    I cannot understand how this is a security issue.

    Consider the facts:

    • If you make the file executable it will run, as you, when you start tscreen.
    • If you do not (the current behaviour) it will not.

    Now if you're in a situation where somebody other than yourself can change permissions/contents of files inside your home directory then you've already lost.

    If nobody but you may change the permissions/content then there is no security hole at all.

    So .. lua? Great idea. Love to see it in screen. But that's not a replacement, and in this context a distraction. If you believe I've introduced a security hole please do explain it to me explicitly!

  7. [gravitar] Bob Proulx Submitted at 01:27:49 on 30 October 2008
    Joe: I see no security concern here. These are your own files. Are you trying to stop your hands from hurting you? They are your own hands. Owen: How would using Lua be more secure than any other language that could be used to create an executable? Comparing languages is like comparing your left hand against your right hand. They are both your own hands. Steve: For comparison sake you might want to compare the method mutt uses in /etc/Muttrc: source /usr/lib/mutt/source-muttrc.d| It has a similar affect but feels different. I am still trying to decide what I like on this issue.