On Sun, Sep 10, 2006 at 12:17:36PM +0200, [EMAIL PROTECTED] wrote: > On 10 Sep 2006 at 13:47, Horms wrote: > > > > there're two solutions: > > > > > > 1. patch the root app to explicitly increase RLIMIT_MEMLOCK > > > via setrlimit(3) before calling mlock/mlockall > > > > > > 2. execute 'ulimit -l unlimited' in the shell and start the > > > root app by hand > > > > > > the former is the correct method but the latter can be used > > > as a quick fix/confirmation at least. > > > > Damien can you see if the second option resolves your problem? > > I will see about geting the 1st adoped upstream if this hasn't happend > > already. > > i took a look at the 1.x and 2.x trees in the meantime and 2.x > has already fixed the problem by doing exactly what i suggested > as well: setrlimit() to set the lockable memory limit to infinity. > in case you want to adopt it yourself, look at the 2.x setrlimit > logic in lib/clplumbing/realtime.c:cl_make_realtime().
Thanks, I'll see about backporting that both to the 1.2.x tree and to the appropriate Debian packges. > > > on a sidenote, based on the grsecurity log, heartbeat drops > > > only its euid from root but not its uid, is that intentional? > > > > I'm not sure, but I will find out. > > i also looked at this code and i think the intention was to drop root > for good (i.e., for all uids) by using setuid and the POSIX behaviour, > therefore there must a bug somewhere else (libc/kernel?) that fails > (in which case other apps could also be affected, this would then be > a security problem). That is interesting. Do you want to poke a bit further? -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
