Re: only one program per login

From: Brian K. White (brian_at_aljex.com)
Date: 05/26/04 

Date: Wed, 26 May 2004 01:53:53 -0400

Stuart J. Browne wrote:
> "Jean-Pierre Radley" <jpr@jpr.com> wrote in message
> news:20040526021350.GA23909@jpradley.jpr.com...
>> Stuart J. Browne typed (on Wed, May 26, 2004 at 12:06:49PM +1000):
>>>
>>>>
>>>> #!/bin/sh
>>>> . /etc/profile
>>>> run myprogram
>>>
>>> wouldn't it also be advisable to 'exec myprogram' at the end of the
>>> script, instead of just running it?
>>
>> Why? When the program exits, and goes back to the script, the script
>> just ends.
>
> *shrug* just a thought.

I don't think it's exactly a stupid idea.

If you had many users logging in at once, and if they each had several
concurrent sessions, then this could be a significantly adviseable step
because it requires one less slot in the process stack (and maybe 3 file
descriptors to go with it?) for each login.

I have verified this by testing.

I just set up a login and changed the login shell to to be a ksh script that
echos $$ and $PPID, does a read junk, then "exec a_binary ..."

while the script is sitting waiting for the enter key, I grep ps -ef for the
ppid and see two processes, telnetd and the script.

I then hit enter in the script, which moves to the binary
Then I ps -ef again in the other session and I see that the same pid that
used to be the ksh script, is now the binary and the ksh script process is
gone.

without the exec, the ksh script keeps occupiing a process slot on it's
original pid but does nothing useful the whole time the binary is running
and the binary gets it's own new pid, tying up 3 altogether
(telnetd/sshd/vtpd/etc..., the script, the binary)

on a 10 to 50 usr box maybe this is inconsequential, but with a lot of
users, and if they are active users with more than one session each, it
could make a difference because the number of available slots to keep track
of concurrent processes is not infinite, and even though the upper limit is
pretty high and can be adjusted higher via kernel tuneable parameters, there
is a performance hit keeping more processes in the stack.

in the simplest case, it means 1/3 fewer process slots in use for logins ,
not counting the processes that are always running regardless of logins.

# ps -ef |grep 6552 |grep -v grep
    root 6552 306 0 00:40:34 ? 00:00:00 telnetd
    blip 6553 6552 0 00:40:34 ttyp4 00:00:00 /u/bw/blip
# ps -ef |grep 6552 |grep -v grep
    root 6552 306 0 00:40:34 ? 00:00:00 telnetd
    blip 6553 6552 0 00:40:34 ttyp4 00:00:00 rclerk phone -s1 -u -h
Phone
#

It also makes the user slightly less likely to be able to break out of the
script to the shell.
They can't stuff the keyboard buffer while still in the binary and cause a
break in that microsecond between binary exit and the next line in the
script. Sure you should be able to secure that with trap and stty but this
is even more sure.

To be really secure, you should make a little c program that replicates the
environment normally set up by /etc/profile and .profile and by the normal
program start script, and calls the binary directly with execve()
http://www.opengroup.org/onlinepubs/009696799/functions/execve.html#tag_03_130_06_05

Compile that c program and specify that as the users login shell rather than
a script.
Then there is never any shell for the user to possibly break out to or trick
from inside a script.

That's certainly less flexable though, or less effortlessly flexable
anyways. 

-- 
Brian K. White  --  brian@aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani

Relevant Pages

  • Re: Detailed logging of ssh sessions
    ... >via ssh). ... come in some way from the login shell. ... I'd just experiment with using script in some way ...
    (freebsd-questions)
  • Re: Hacker activity?
    ... >login to a server, most as root but some are attempts to login to ... >telnet, all come from the same remote server, and all fail. ... >getting some odd cgi calls to a script on a secure ssl server. ... Make sure root cannot login to your system via ssh. ...
    (freebsd-questions)
  • Re: [opensuse] BASH: has $COLUMNS gone nuts?
    ... You do realize that lines & columns are dynamic values which at least some terminals and login daemons will continuously adjust right? ... What the above shows is that I dragged the corner of my PuTTY window (which was connected to sshd, not every terminal client nor every server daemon does this) making the window a little larger and without issuing any commands, and no possibility that any bashrc or inclusions got executed, the values changed, because the terminal told the daemon and the daemon told it's child processes. ... Try calling them from within a script: ... Although, I would also actually be perverse and say that since the SCO systems predate most others, including ALL linux, that you could actually make the argument that the dwindling remaining production sco boxes in the world are right and the 90 million linux & freebsd & sun boxes are all wrong. ...
    (SuSE)
  • Abusing poor programming techniques in webserver scripts V 1.0
    ... $login = Request.Form ... fool the database parser. ... verified in the script of access to the database, ... The SQL statement will be parsed by the database manager, ...
    (SecProg)
  • Re: Limit desktop & start menu
    ... Create a login script that runs when users log into the TS, and map the R: ... persisitent "R" drive on the server itself and that may cure it. ...
    (microsoft.public.windows.terminal_services)