> 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).
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
