[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110605191747.GA6174@albatros>
Date: Sun, 5 Jun 2011 23:17:47 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: kernel-hardening@...ts.openwall.com
Subject: Re: procfs mount options
Solar,
On Sun, Jun 05, 2011 at 00:59 +0400, Solar Designer wrote:
> > > This is not generic, but at least it's simple, not
> > > confusing, and it allows for future changes (we may change what exactly
> > > restricted means).
> >
> > Changing what some option means after implementing it is a ABI breakage,
> > which is terrible for upstream.
>
> This depends on how the option is defined initially. It is possible to
> define the option as "enabling unspecified version-dependent restrictions,
> which are subject to change across kernel versions and builds". ;-) OK,
> the word "unspecified" may be dropped.
Everything that is implemented should behave the same way it was
initially implemented, regardless of what is explicitly marked as "ABI".
This is upsteam's way to define "ABI" term. Often they deliberately
break such ABI, but normally this is not encouraged.
> Here's a related thought: if these mount options happen to affect all
> instances of the filesystem (in the same container), maybe they should
> be sysctl's instead?
AFAIR, only net namespaces have their own sysctl sets. Other sysctls
are global. So, implementing pid_namespace-specific sysctl would be a
bit weird (according to current policies).
Thanks,
--
Vasiliy
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
