Bug#625226: Patch redux

May 24th, 2011 - 01:50 pm ET by Dominique Brazziel | Report spam

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>

After inserting the patch in the quilt series and doing:

dpkg-buildpackage -b > ./dpkg-buildpackage.log 2>&1

(having a log of the output of 'dpkg-buildpackage' process proved very
instructive), then pointing the /etc/pam.d/ files to the new
pam_limits.so,
'Max realtime timeout' is recognized.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2">
</HEAD>
<BODY>
    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> 
 
After inserting the patch in the quilt series and doing: 
 
dpkg-buildpackage -b > ./dpkg-buildpackage.log 2>&1 
 
(having a log of the output of 'dpkg-buildpackage' process  proved very 
instructive), then pointing the /etc/pam.d/ files to the new pam_limits.so, 
'Max realtime timeout' is recognized. 
 
</BODY>
</HTML>

To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Follow the discussion Replies

1 reply

Make a reply

Replies

#1 Steve Langasek

May 24th, 2011 - 02:30 pm ET | Report spam

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/

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Read all the answers

Bug#625226: Patch redux

Replies

Similar topics