linux-kernel - Re: [PATCH 2/2] cgroup: add xattr support

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]

Date:	Wed, 18 Jan 2012 22:28:42 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	Li Zefan <lizf@...fujitsu.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Cgroups <cgroups@...r.kernel.org>,
	Lennart Poettering <mzxreary@...inter.de>
Subject: Re: [PATCH 2/2] cgroup: add xattr support

On Tue, Jan 17, 2012 at 18:53, Tejun Heo <tj@...nel.org> wrote:

>> > The key idea is that this would allow attaching runtime meta information
>> > to cgroups and everything they model (services, apps, vms), that doesn't
>> > need any complex userspace infrastructure, has good access control
>> > (i.e. because the file system enforces that anyway, and there's the
>> > "trusted." xattr namespace), notifications (inotify), and can easily be
>> > shared among applications.

> Ummm... I don't feel too good about this.  Why can't those extra
> information be kept somewhere else?  Overloading cgroupfs as storage
> for essentially opaque userland information doesn't seem like a good
> idea to me.

A bit of the background:

The /sys/fs/cgroup/systemd/ hierarchy represents something like a
first class kernel-related system object, which we call an
'application' or 'service' in userspace. Every 'service' or
'application' has zero, one or many processes, and has some high-level
metadata attached.

The general idea, not specifcally related to cgroups, is to try as
hard as possible to stick metadata about objects to the objects
themselves. It's a bit like the difference of lock files vs. locks
attached to a process. In the later case, if the process dies, the
lock is automatically cleaned up, in the former, we have a stale file.

The idea with the cgroup fs xattrs was to be able to attach some
general useful attributes to the 'service container' itself, instead
of keeping them in the memory of the managing process or store them on
disk which can get out-of-sync much easier.

Kay
--
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/