Well, are you sure you're using that thing correctly?

Friday, 31 October 2008

In response to the comments left on my previous entry about executable configuration files I've changed the way that tscreen works.

There is still support for using an arbitrary shell script or binary as a configuration file, but you must be explicit to enable it:

#  Load the dynamic section, if it exists.
if -x ~/.tscreen.dynamic  'source ~/.tscreen.dynamic|'

The change here is the trailing "|" on the argument to the source command:

source ~/foo/bar

Opens ~/foo/bar and parses the contents. (Assuming it exists.)

source ~/bin/blah|

Executes ~/bin/blah and parses the output. (Assuming it exists)

I still see no security risk with the previous setup, but I'm happy to apply a little misdirection if that makes people feel better.

ObFilm: Ghostbusters



Comments On This Entry

[gravitar] Marek

Submitted at 11:45:53 on 31 october 2008

One accident which could happen that just came to mind: say you've copied your tscreen config to an SMB share, and then back off again, you might suddenly find it's gained x. Of course, no *real* UN*X sysadmin would do this, and I doubt a static tscreen config would execute! But I agree it might be better to have the safety catch of a | to stop kids shooting themselves in the foot.
[gravitar] Jonathan Wakely

Submitted at 11:51:19 on 31 october 2008

How about checking the file owner and mode, as ssh does for the .ssh dir and authorized_keys file? If it's writable by anyone except you, refuse to execute it. That could still be done even if you have to explicitly-enable the feature with the trailing "|"
[author] Steve Kemp

Submitted at 12:17:37 on 31 october 2008

Checking ownership, and similar, are good things to think about for the future. But mostly I think that by making this explicit I've done "enough".

I could easily imagine a root owned /usr/local/bin/gen-screenrc script which was installed system-wide to handle a whole bunch of users and a simple uid test would fail to handle this.

[gravitar] Jonathan Wakely

Submitted at 17:32:33 on 31 october 2008

Yes, I did think of that. It could be handled easily enough by making the user install a file with the right mode and permissions, containing nothing but ". /usr/local/bin/gen-screenrc" but as you say, your current solution is good enough.


Comments are closed on posts which are more than ten days old.

Recent Posts

Recent Tags