Hi Dominique, Thanks for the patch.
On Tue, May 24, 2011 at 01:45:41PM -0400, Dominique Brazziel wrote: > After RTFM (debian/README.source from the source tree, which > references > the excellent /usr/share/doc/quilt/README.source) I got a handle on the > patch > system and put together a less messy and more precise patch: > 099_pam_limits_include_rttime_nrlimits16.patch > Index: pam-1.1.2/modules/pam_limits/pam_limits.c > =================================================================== > --- pam-1.1.2.orig/modules/pam_limits/pam_limits.c 2011-05-24 > 12:01:59.000000000 -0400 > +++ pam-1.1.2/modules/pam_limits/pam_limits.c 2011-05-24 > 12:24:29.000000000 -0400 > @@ -30,6 +30,14 @@ > #include <sys/types.h> > #include <sys/stat.h> > #include <sys/resource.h> > + > +// Temporary workaround for #627619, #625226 > +#ifndef RLIMIT_RTTIME > +#define RLIMIT_RTTIME 15 > +#undef RLIM_NLIMITS > +#define RLIM_NLIMITS 16 > +#endif > + > #include <limits.h> > #include <glob.h> > #include <utmp.h> This is dangerous; the value of RLIMIT_RTTIME is not guaranteed to be the same across all systems, so by statically defining it here instead of relying on a system definition, we're potentially overwriting a different limit with values that are intended to be used as rttime. This is not likely to be a problem at all on Linux kernels which all use the same values, but on non-Linux systems (such as the hurd and kfreebsd ports), this is a potential security issue. So we can't apply this patch as-is. We could guard the definition with a check for a Linux kernel; or we could just wait for linux-libc-dev to be updated. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
