On 16 November 2010 10:57, Richard W Jerrido <[email protected]> wrote:
>
>>
>> You are correct. You cannot (AFAIK) make the read-only status persist
> across an exec. But you can ensure (to a certain extent) that the TMOUT
> variable gets defined again. That is why I suggested placing the commands in
> an /etc/profile.d/ file as this gets sourced by both /etc/profile and
> /etc/bashrc. Granted, this method isn't perfect as it doesn't stop an
> enterprising user from running exec bash --noprofile --norc and blowing this
> whole theory out of the water. But as long as one understands its
> limitations, it works fairly well.
>
>
I wonder how long it would take for someone to discover
if test -n "$TMOUT" && ! unset TMOUT 2>/dev/null; then exec bash; fi
or something like than and tell everyone else. If you want to time out
shells without users being able to circumvent the timeout (which seems a
little draconian to me) then something like this probably stands a better
chance of working:
now=$(date +%s)
for proc in /proc/[0-9]*; do
if [[ $(readlink $proc/exe) == "/bin/bash" ]]
then idle=$(($now - $(stat -L --format %X $proc/fd/0)))
test $idle -gt 900 && kill -HUP ${proc#/proc/}
fi
done
The test is a little imprecise: it finds shells that don't have stdin
attached to something in /dev and shells that aren't interactive (for
example, the shell script that wraps firefox and thunderbird) but I think
you can improve the test to make it less susceptible to false-positives —
checking that stdin is (for example) /dev/pts/* is probably the first
improvement I would make. And then I'd have a better way of identifying
shells, including checking for something that's just a copy of /bin/bash and
making sure you don't kill a shell that has child processes (unless you want
to kill a shell that's running an idle editor with an unsaved file).
Maybe the read-only TMOUT is better. It looks as though you've tried and
not actually caused problems for anyone or actually stopped someone from
staying logged in if that's what they want to do.
jch
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
