Re: ulimit

On Thu, 08 Nov 2007, in the Usenet newsgroup, in article
<1194494735.248243.325540@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, Steven Borrelli wrote:

NOTE: Posting from (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.

And please don't post the same question to multiple newsgroups.

How can I (being root) prevent other users from changing their ulimit?

You can't. They can _reduce_ their limits, or increase them up to
the limits you set, but it's not easy to prevent anyone from changing
them below those maximum limits.

I know this is possible in UNIX, but I'm not sure about Linux (i.e.
Slackware, SUSE). By the way, how would I do it in UNIX? (i.e.
Solaris, Darwin, or FreeBSD)

It's a _shell_ function, not an O/S. You're probably running a Bourne
type shell (sh, bash, ksh, or similar), and for that the built-in
command is 'ulimit'. For a 'c' type shell (csh, tcsh, and similar),
the command is 'limit'.

Limits are set in a login shell - so if you are using a text based
login and a Bourne shell, use /etc/profile. If using a 'csh' shell,
use ~/.login in the users home directory. If using a 'tcsh' shell,
see the man page, as things vary as a function of how the shell is
compiled. For a _GUI_ login (runlevel 5 in an Linux Standard Base
compliant distribution)[1], you need to look at the man page for the
display manager used (gdm, kdm, wdm, xdm, etc.) as they usually
do NOT use a shell as the place to set things - .xinitrc, .xsession,
or similar - often in the user's home directory. For those files
that set the limits but are located _in_ the user's home directory,
you need to change ownership of that/those files to root:root, and
set the 'sticky bit' on the directory itself (chmod 1750 /home/mumble)
so that only the file _owner_ can delete the file.

Bottom line - see the man page for the shell used, and read the
sections about limits and shell invocation.

Old guy

[1] Mandriva 2008 is an exception. The GUI login shell scripts source
~/.bash_profile - which isn't much good in a 'csh' environment, but is
a start.