On Tue, Jan 26, 2010 at 06:11:38PM +0100, Lars Olav Dybsjord wrote:
> Another solution could be to let the screensaver set /proc/self/oom_adj to
> -17 to disable the possibility of this process beeing killed by the
> oom-killer.
This needs root priviledges (CAP_SYS_RESOURCE to be exact).
Bastian
Hi,
On Dienstag, 26. Januar 2010, Julien Cristau wrote:
> Not really, because everyone will re-enable it anyway.
I think your definition of "everyone" is flawed. I assume at least 98% of the
users not knowing about sysrq and I'd expect the same percentage to think
that it's not possible to kil
On 2010-01-26 17:31, Josselin Mouette wrote:
> Le mardi 26 janvier 2010 à 16:19 +0100, Guido Günther a écrit :
> > > True, but this one is trivial to exploit and is also fairly easy to
> > > prevent so
> > > why stick with it?
> > I can only agree here. procps should at least get a:
> >
> > sys.
On Tue, Jan 26, 2010 at 17:31:23 +0100, Josselin Mouette wrote:
> Le mardi 26 janvier 2010 à 16:19 +0100, Guido Günther a écrit :
> > > True, but this one is trivial to exploit and is also fairly easy to
> > > prevent so
> > > why stick with it?
> > I can only agree here. procps should at least
On Tue, Jan 26, 2010 at 05:31:23PM +0100, Josselin Mouette wrote:
> Le mardi 26 janvier 2010 à 16:19 +0100, Guido Günther a écrit :
> > I can only agree here. procps should at least get a:
> > sys.kernel.sysrq = 0
> It’s only a workaround, and it’s a bit too much to disable all SysRq
> since other
Le mardi 26 janvier 2010 à 16:19 +0100, Guido Günther a écrit :
> > True, but this one is trivial to exploit and is also fairly easy to prevent
> > so
> > why stick with it?
> I can only agree here. procps should at least get a:
>
> sys.kernel.sysrq = 0
It’s only a workaround, and it’s a bit t
On Tue, Jan 26, 2010 at 03:25:33PM +0100, Nico Golde wrote:
> Hey,
> * Bastian Blank [2010-01-26 14:44]:
> > On Tue, Jan 26, 2010 at 11:21:56AM +0100, Josselin Mouette wrote:
> > > Le samedi 23 janvier 2010 à 11:37 +0100, Guido Günther a écrit :
> > > > Should this really be handled in the screens
On Tue, Jan 26, 2010 at 02:15:13PM +0100, Josselin Mouette wrote:
> Le mardi 26 janvier 2010 à 12:00 +0100, Bastian Blank a écrit :
> > The OOM killer can always be forced with normal processes as long as
> > over-commitment is enabled. So it is never save to add security measures
> > within proces
Hey,
* Bastian Blank [2010-01-26 14:44]:
> On Tue, Jan 26, 2010 at 11:21:56AM +0100, Josselin Mouette wrote:
> > Le samedi 23 janvier 2010 à 11:37 +0100, Guido Günther a écrit :
> > > Should this really be handled in the screensaver? The user can also kill
> > > other processes during boot like ac
Le mardi 26 janvier 2010 à 12:00 +0100, Bastian Blank a écrit :
> On Tue, Jan 26, 2010 at 11:21:56AM +0100, Josselin Mouette wrote:
> > Le samedi 23 janvier 2010 à 11:37 +0100, Guido Günther a écrit :
> > > Should this really be handled in the screensaver? The user can also kill
> > > other process
On Tue, Jan 26, 2010 at 11:21:56AM +0100, Josselin Mouette wrote:
> Le samedi 23 janvier 2010 à 11:37 +0100, Guido Günther a écrit :
> > Should this really be handled in the screensaver? The user can also kill
> > other processes during boot like accounting daemons and therefore
> > compromise secu
Le samedi 23 janvier 2010 à 11:37 +0100, Guido Günther a écrit :
> Hi,
> Should this really be handled in the screensaver? The user can also kill
> other processes during boot like accounting daemons and therefore
> compromise security. The only "fix" is to disable this feature.
I fully concur. Su
12 matches
Mail list logo
