linux-kernel - Re: [RFC] [PATCH] Re: Prefixing cgroup generic control filenames with "cgroup."

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6599ad830802290959h5a736820i591ced2813f3014f@mail.gmail.com>
Date:	Fri, 29 Feb 2008 09:59:00 -0800
From:	"Paul Menage" <menage@...gle.com>
To:	"Paul Jackson" <pj@....com>
Cc:	akpm@...ux-foundation.org, containers@...ts.osdl.org,
	linux-kernel@...r.kernel.org, balbir@...ux.vnet.ibm.com,
	a.p.zijlstra@...llo.nl, xemul@...nvz.org
Subject: Re: [RFC] [PATCH] Re: Prefixing cgroup generic control filenames with "cgroup."

On Fri, Feb 29, 2008 at 7:30 AM, Paul Jackson <pj@....com> wrote:
>
>  The pattern might be stronger (more restrictive) than "[a-z].*"
>
>  The pattern might be something like:
>   1) the known set of existing names (a short, specific list), plus
>   2) "[a-z]+\.[a-z]+(_[a-z]+)*"

Why make it more complex? If we're going for a solution that involves
an implicit partition of the namespace that the user has to be aware
of, then simple is good.

>  Note here "safe for user created" names just means safe from collision
>  with kernel generated names, not necessarily safe from collision with
>  other user generated names.
>
>  That is regardless of what you do here, you cannot protect the
>  delicate user from possible collision.  You can only protect them
>  from collision with "your" names.

Of course - I don't think anyone's suggesting that the kernel can do
anything about two competing users fighting over who gets to create
cgroup "Foo". But IMO it's crazy to have multiple uncoordinated
userspace cgroup managers.

>  > >  And did I say incompatible with released versions?
>  >
>  > Not at all incompatible if it requires a mount option to enable it ...
>
>  Ah - are you saying I missed another detail?

That was one of the questions that I left open - we could add it
defaulting to off, unless a mount option was given.

>
>   /mnt/cgroup/groups/user_created_groupname1/groups/user_created_groupname2
>  or
>
>   /mnt/cgroup/user_created_groupname1/user_created_groupname2

Correct.

>
>  So code that knows something about these paths has to work with either
>  form (since not all code using these paths will control the mount
>  relevant option.)

Yes, but compared to all the other configuration details that a
userspace cgroup manager needs to work with, I think this would be a
minor one.

>
>  I hope I misunderstood something here.
>
>
>  > That leaves a bit of an ugly taste in my mouth  ...
>
>  Could you spell out the key reason -you- find it distasteful,  perhaps
>  for a stronger pattern such as "[a-z]+\.[a-z]+" I consider above?
>  Perhaps I'm missing some reason to share in your revulsion.

The main reason it's not my primary choice is that it's an implicit
rule that the user has to know about or risk getting bitten in future.
Making that rule complex is even worse, I think.

Of course it does have the big advantage that no code changes are
needed, just documentation. So if people prefer it, then I'm not going
to fight hard.

Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/