linux-kernel - Re: [PATCH 1/2] cgroup allow subsys to set default mode of its own file

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20090226130005.3282cb02.akpm@linux-foundation.org>
Date:	Thu, 26 Feb 2009 13:00:05 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Cc:	linux-kernel@...r.kernel.org,
	containers@...ts.linux-foundation.org, menage@...gle.com,
	lizf@...fujitsu.com, balbir@...ux.vnet.ibm.com
Subject: Re: [PATCH 1/2] cgroup allow subsys to set default mode of its own
 file

On Wed, 25 Feb 2009 16:35:55 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> wrote:

>  When I wrote tools for maintain cgroup, I can't find which file is
>  writable intarfece or not via cgroup file systems. (finally, I did
>  dirty approach.)
>  IMHO, showing "this file is read-only" in explicit way is useful
>  for user-land (tools). In other story, a file whose name sounds read-only
>  may have "trigger" operation and support reseting. In this case,
>  "writable" is informative.

Well, we have compatibility issues here.  If we make this change, and
people write tools which depend upon that change then those tools might
break when run upon older kernels.  Or they need back-compatibility
additions, which increases the testing burden of those tools.

One way in which we could improve this situation is to backport these
changes into earlier kernels, although I don't know which versions.

What do we think?
--
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/