* Grzegorz Pawel Szostak said: > > and CPU time. The rest is just fine tuning the other parameters - after all, > > the data and stack is what takes 90% of the space. Limiting the image size > > of the binary executable is pointless - you've got full control over what > > the user can or cannot execute - just deny him the right to execute anything > > from his/her home directory. > but what happens when he/she run: /lib/ld-linux.so.2 $HOME/any_executable > ? It works! And what happens if s/he does 'ln -sf /etc/passwd moo' and then opens 'moo'? It works - your kernel code will look for /etc/passwd or passwd or whatever and not /home/lameuser/moo. On what level you will implement that call? VFS or FS? If you are soo worried about it, don't use dynamically linked binaries... But either way, I think that what you're talking about is an unjustified paranoia - if you don't want you users to know who's on the system, close each and every one of them in a chroot jail or deny shell access. > > true. As a side note - tcsh takes half the memory bash consumes and has all > > the sprinkles bash does. :)) > > > > > ulimit -d 2097148 -c 0 -n 64 -s 8192 -u 64 -l 4096 -m 4096 -v 8192 > > > > > > and it is good enough for me. > > And what about your user who wants to use ash, sash, csh, ksh, zsh, rc, > > pdmenu or whatever other shell s/he ... > They first use bash ... but i'm not sure if bash leavs environment ... A bogus argument. They can change to some other shell, or invoke some other program directly using ssh - what will you do then??? Come up with a similar solution for every (un)imaginable shell? You said you have no time - but you are willing to waste time IMO. marek
Attachment:
pgp6NIr5R0vh5.pgp
Description: PGP signature