linux-kernel - Re: [RFC] [PATCH -mm] cgroup: uid-based rules to add processes efficiently in the right 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 for Android: free password hash cracker in your pocket

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

Message-ID: <6599ad830808181405i3ec1f9fdp4d8ca7ab675b2c5f@mail.gmail.com>
Date:	Mon, 18 Aug 2008 14:05:36 -0700
From:	"Paul Menage" <menage@...gle.com>
To:	righi.andrea@...il.com
Cc:	"Vivek Goyal" <vgoyal@...hat.com>,
	"KAMEZAWA Hiroyuki" <kamezawa.hiroyu@...fujitsu.com>,
	"Balbir Singh" <balbir@...ux.vnet.ibm.com>,
	"linux kernel mailing list" <linux-kernel@...r.kernel.org>,
	"Dhaval Giani" <dhaval@...ux.vnet.ibm.com>,
	"Kazunaga Ikeno" <k-ikeno@...jp.nec.com>,
	"Morton Andrew Morton" <akpm@...ux-foundation.org>,
	"Thomas Graf" <tgraf@...hat.com>,
	"Ulrich Drepper" <drepper@...hat.com>
Subject: Re: [RFC] [PATCH -mm] cgroup: uid-based rules to add processes efficiently in the right cgroup

On Sun, Aug 17, 2008 at 3:33 AM, Andrea Righi <righi.andrea@...il.com> wrote:
>
> [ I wrote this patch for a "special purpose" environment, where a lot of
> short-lived processes belonging to different users are spawned by
> different daemons,

What kinds of daemons are these? Is it not possible to add some
libcgroup calls to these daemons?

I'm reluctant to add features like this to the kernel side of cgroups
due to their "magical" nature - any task that does a setuid() now
risks being swept off into a different cgroup.

Having the cgroup attachment done explicitly e.g. by a PAM library at
login time is much less likely to cause unexpected behaviour.

Maybe if we had a way to control which tasks the magical setuid
switching occurs for, it might be more acceptable. (Perhaps base it on
the cgroup of the task that's doing the setuid as well?

Other thoughts:

- what about other uids (euid, fsuid)?

- what about multiple hierarchies?

- if the attach fails, userspace gets no notification.

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/