On 26 Jan 2011 at 17:03, Pierre Ynard wrote:
> mprotect(0x4946b000, 3840, PROT_READ|PROT_WRITE) = -1 EACCES (Permission
> denied)
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> +++ killed by SIGSEGV +++
> zsh: segmentation fault strace -f /usr/lib/vlc/vlc-cache-gen
> /usr/lib/vlc/plugins
>
>
Hello,
i see two potential issues with radeontool:
1. the author is somewhat confused over the usage of mmap, there's
no need to malloc memory beforehand and then overmap it. in fact,
it's a very bad thing to do.
2. grsec has checks on what can be mmap'ed from /dev/mem, have you
enabled
On 10 Sep 2006 at 21:55, Horms wrote:
> > 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 als
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 for
the problem is that in 2.6.13 or so the default rlimit for
locked memory has been changed for both root and non-root
users, in particular they all get 8 pages by default. this
in turn catches unaware root apps by surprise (ntpd comes
to mind) as they no longer can mlock/mlockall beyond these
8 page
5 matches
Mail list logo
