bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ssh as user: setrlimit failed


From: James Morrison
Subject: Re: ssh as user: setrlimit failed
Date: Sun, 7 Oct 2001 16:19:30 -0700 (PDT)

--- Roland McGrath <roland@frob.com> wrote:
> > I have found the offending piece of code.
> > 
> >        original_real_uid = getuid();
> >         original_effective_uid = geteuid();
> > 
> > #ifdef HAVE_SETRLIMIT
> >         /* If we are installed setuid root be careful to not drop
> > core. */
> >         if (original_real_uid != original_effective_uid) {
> >                 struct rlimit rlim;
> >                 rlim.rlim_cur = rlim.rlim_max = 0;
> >                 if (setrlimit(RLIMIT_CORE, &rlim) < 0)
> >                         fatal("setrlimit failed: %.100s",
> > strerror(errno));
> >         }
> > #endif
> > 
> >   Should GNU Hurd be changed to accomodate this or vice-versa?
> 
> This usage is entirely proper and the problem is definitely on our
> end.
> I've redirected to the bug-hurd list, since that's the right place
> to
> discuss the details of the bug.
> 
> We don't really have resource limits implemented.  What we have is
> very
> half-assed, and should do whatever makes the most programs happy
> without
> too much giving the impression that limits really exist where they
> actually
> don't.  (In fact, the only limits that really work are
> RLIMIT_NOFILE,
> RLIMIT_DATA--which controls only sbrk, and RLIMIT_CORE--which
> really only
> works when set to 0, not to limit the size of a core file.  That
> latter
> failing is at least mitigated by the fact that we don't have
> dumping core
> files implemented either! :-)
> 
> I am open to suggestions on what the setrlimit function in libc
> should do.
> Currently it fails with ENOSYS if rlim_max (the hard limit) so set
> to
> anything other than RLIM_INFINITY.  It lets you set rlim_cur (the
> soft
> limit) to whatever you like, for all the limits, even though most
> of them
> don't really do anything.  I suppose it wouldn't hurt to just
> permit
> setting the hard limits however you like as well (though actually
> we don't
> save them).  
> 

For now at least for RLIMIT_CORE I think we should just accept any
hard maximum.  However, to implement core dumps would that be 
a core server that actually implemented limits on core sizes and
such?



=====
James Morrison
   University of Waterloo
   Computer Science - Digital Hardware
   2A co-op
http://hurd.dyndns.org

__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1



reply via email to

[Prev in Thread] Current Thread [Next in Thread]