linux-kernel - Q: using cgroups in real life

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-next>] [day] [month] [year] [list]

Message-Id: <50A3B0A6020000A10000D757@gwsmtp1.uni-regensburg.de>
Date:	Wed, 14 Nov 2012 14:54:30 +0100
From:	"Ulrich Windl" <Ulrich.Windl@...uni-regensburg.de>
To:	<linux-kernel@...r.kernel.org>
Subject: Q: using cgroups in real life

Hi!

I have a question on cgroups (as of Linux 3.0):
The concept is to mount a filesystem, and configure cgroups through it. This implies that all the files belong to root (or maybe some other fixed user).

AFAIK, you can chmod() and chown() files, but these bits are only kept in the i-node cache, so they may change at any time.

I think this is bad, because if you want to allow users to limit (maybe memory usage) by using some predefined cgroup, the user needs at least partial write access to that cgroup (to add the PID). Probably this also means the user could add any PID (even those processes not owned by him).

The alternative is that a privileged task manages cgroups and PIDs. This is difficult, for example, if the process to control does not exist yet (e.g. the user logs in and then starts some process). It's getting tricky if the user maybe runs some big fat database (which should work at peak performance), and later logs in to do a backup of the database (which is not time critical, and should not steal all the I/O bandwidth). I wonder how a solution would look like to allow the user to limit the bandwidth (maybe use of page cache, too) of the backup in an reliable way.

Being paranoid, the user should at most be able to limit his own processes. I cannot envision a proper solution with the current interface.

Would anybody share some good ideas with me?

(I'm not subscribed to the kernel list, so please CC:)

Regards,
Ulrich

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