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
| ||
|
Date: Thu, 28 Feb 2008 17:03:33 -0800 From: "Paul Menage" <menage@...gle.com> To: "Paul Jackson" <pj@....com> Cc: containers@...ts.osdl.org, linux-kernel@...r.kernel.org, balbir@...ux.vnet.ibm.com, a.p.zijlstra@...llo.nl, xemul@...nvz.org, akpm@...ux-foundation.org Subject: Re: [RFC] Prefixing cgroup generic control filenames with "cgroup." On Thu, Feb 28, 2008 at 3:36 PM, Paul Jackson <pj@....com> wrote: > > We could accomplish that much by decreeing that future new kernel > generated names that we might add follow some stronger convention, > such as the cgroup_ or appropriate subsystem prefix. Subsystem-created files already have an appropriate prefix. > No need to > change the existing well known names for this reason. But that's part of my point - is it reasonable to describe a system that was only introduced in 2.6.24 as "well-known"? > > Actually, in terms of 'common names used > by humans' some of these names, "tasks" and "notify_on_release", date > back much earlier than that. Please don't rename these two files in > cgroups; and of course absolutely don't rename them in cpusets. No, I wasn't planning to make any changes to cpusets. > > Please don't end up with different names of these files, depending on > whether you're in cgroups or cpusets, either. That already happens - when mounted as the "cpuset" filesystem, we have names like "mems_allowed". When mounted as cgroups, we have names like cpuset.mems_allowed. > > > Could we do something like auto-prefixing user-created directories with a > > fixed string so that there is no way in which the user can cause a > > collision with kernel-created files? > > Lordy lordy -- a bunch of intrusive, complicating crap to solve a > non-existent problem (sorry for the indelicate choice of words ;). No, I don't like that idea either. 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/
Powered by blists - more mailing lists