On Fri, 04 Feb 2000, Kelly Lynn Martin <[EMAIL PROTECTED]> wrote:
> On Fri, 4 Feb 2000 09:52:30 +0100 (MET), [EMAIL PROTECTED] (Raphael Quinet) said:
> >I disagree.  This would only encourage some users to re-compile their
> >own version of the Gimp in a private directory in order to get around
> >the hardcoded limits.
> Frankly, I disagree.  Systems where admins are likely to impose such
> restrictions are going to be ones where users don't have enough space
> to compile private copies of Gimp.

I wouldn't be too sure about that.  On a system that I was previously
administering (students' network at the university), I have seen some
users that were using /var/tmp or /tmp to store their applications
while they were logged in, and deleted the stuff afterwards.  The
quota was something like 5 Mb on the home directory and much larger in
the temporary directories (for good reasons) so they took advantage of
that.  Some of them were re-compiling every time, some others had
stored the compiled binaries on some external ftp servers and were
downloading them in /tmp every time they needed them.  This had some
obvious impact on security...  Some other users were hiding their
applications in some system directories that had to be writable by
all, such as /usr/local/lib/emacs/lock or /var/spool/mail...

Anyway, I would not be surprised that any limit that could be
hardcoded in the Gimp would be circumvented by some frustrated users
who would re-compile their own version of the main executable and put
it somewhere when they need it.  And as Mark said in another message,
it is not our job to enforce local policies (of course we should not
make them un-enforceable either) so if the admin wants to restrict
disk or memory usage, they should use other means than the Gimp:
ulimit and quota are some examples.

> >Being a system administrator myself, I believe that an admin should
> >always suggest some limits (and maybe use some social engineering to
> >encourage users to respect these limits) but should avoid hard
> >limits.   
> It depends on the kind of users you have and the hardware you're
> running.  Imposing hard limits is sometimes the only way to deal with
> certain types of users.

Yes, it is sometimes very hard to convince some users.  But here is an
example: on one system with limited disk space (old DEC 3100 Ultrix
workstations), we had set up some quotas and the disks very constantly
full.  All users were using the maximum space available under their
quota, and they only started cleaning up when they had exceeded their
quota.  Then we tried an experiment: instead of decreasing the quotas,
we decided to increase them significantly for everybody, but every
week a "high score" list of disk usage was printed at the entrance of
the terminal room, with the names of the top 50 users.  This was not a
perfect solution, but there was enough social pressure to make sure
that nobody stayed at the top of the list for a long time.  This
solved several problems: most users started to clean up their home
directory before entering the top 20, and those who had a valid reason
to consume more disk space could easily explain it to the others.
Those who could not explain why they consumed so much disk space had
to make some room so that others could continue working.  Well, that's
only an example and it cannot be applied in all cases (e.g. the users
have to know and trust each other to some extent, otherwise such a
system will just generate suspicion or hatred between them).  Ah well,
it looks like I got carried away and this is off-topic for this list.

> >On the other hand, if ulimits are used to limit the maximum file size
> >or CPU usage, there is not much that we could do about it.  Same if
> >disk quotas are activated.  The Gimp can have some control over its
> >memory usage, but many parts of the code assume that the disk space
> >is unlimited (or is not the main constraint).
> Yup.  It might be nice to catch SIGXCPU and try to do an orderly
> shutdown before the SIGKILL does ya' in, though. :)

As long as this is not in glib or libgimp, otherwise I know that some
members of this list would complain about plug-ins and signal handlers

On second thought...  The default for SIGXCPU and SIGXFSZ is to
generate a core dump.  Maybe it would be better to get a core dump and
be able to get whatever is left inside, instead of desesperately
trying to save the file and getting a SIGKILL while this is in
progress?  On third thought...  If your disk quota is exceeded, you
will not even get the core dump.  On fourth thought... :-)  Who in
their right mind would use the Gimp on a systems that has such strict


Reply via email to