About Archive Tags RSS Feed


Bring me everyone.

27 October 2008 21:50

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:


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

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:


# common config
cat ~/.tscreenrc.common

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

# 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

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



Comments on this entry

icon Joe Buck at 23:34 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.

icon Anonymous at 01:09 on 28 October 2008
Wow, *nice*. More programs should do exactly that.
icon Des at 01:46 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
if [ -e "$file" ]; then
   cat $file
if [ x$TSCREEN_SOCKET_NAME -eq xweb ]; then
  echo screen lynx http://google.com
  echo screen lynx http://slashdot.org
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...)
icon Steve Kemp at 09:24 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!

icon Owen Synge at 22:32 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.
icon Steve Kemp at 22:40 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!

icon Bob Proulx at 01:27 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.