Awesome use of read-only variables in bash scripts

I was reading through Jim Perrin’s CentOS hardening article, and saw one super interesting use of read-only bourne shell variables. If you have users that are frequently logging in and staying idle for days and or weeks, you can add a readonly TMOUT variable to /etc/profile:

$ echo “readonly TMOUT=3600” >> /etc/profile

The TMOUT variable controls the amount of time a user can be idle before the system logs them out. Since the variables in /etc/profile will be applied to the environment before a users .bash* and .profile files, you can be sure that users can’t override (this doesn’t address users who use C shells, but that can be addresses similarly) the read-only TMOUT variable and stay idle for longer periods of time. This also works well for HISTFILE environment variable, which is mentioned in the article. Great article Jim!


Alex  on July 18th, 2009

What if you exec a new bash process or shell will the timeout be honoured ?

guichaz  on July 18th, 2009

Users will only have to run ‘bash’ to get a new shell without the readonly TMOUT as it won’t read /etc/profile, and even if it did, ‘bash –noprofile’ to the rescue, no?

Frank  on July 20th, 2009

And as HISTFILE is writeable by the user, it shouldn’t be too hard to link HISTFILE to /dev/null. And I’m not convinced that protecting HISTFILE and ‘reaping’ idle users enhances the overall security of a system.

Though there are points that should be common sense, like ‘noexec,nodev,nosuid’ for /tmp and the like.

rayvd  on July 20th, 2009

But wouldn’t the parent shell still terminate?

honglus  on July 22nd, 2009

Instead of adding to /etc/profile.
/etc/bashrc /etc/kshrc .. can make the value valid even after invoking new shell.

Leave a Comment