linux-kernel - Re: [RFC] How to handle the rules engine for cgroups

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]

Message-ID: <48763129.9060903@redhat.com>
Date:	Thu, 10 Jul 2008 08:56:25 -0700
From:	Ulrich Drepper <drepper@...hat.com>
To:	Vivek Goyal <vgoyal@...hat.com>
CC:	Rik van Riel <riel@...hat.com>, Paul Menage <menage@...gle.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Libcg Devel Mailing List <libcg-devel@...ts.sourceforge.net>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
	Peter Zijlstra <pzijlstr@...hat.com>,
	Kazunaga Ikeno <k-ikeno@...jp.nec.com>,
	Morton Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Graf <tgraf@...hat.com>
Subject: Re: [RFC] How to handle the rules engine for cgroups

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vivek Goyal wrote:
>>    it can even be hidden from the application by hooking into
>>    the exec() call
>>
> 
> This means hooking into libc. So libc will parse rules file, determine
> the right cgroup, place application there and then call exec?

As with any "solution" based on userlevel code, the problem is overhead
and interfaces.

Such a rules file would be a real file, I assume, and as such we'd have
to read it every time an exec call is made.  At least we'd have to check
using a stat() call that nothing changed.  That's always a big overhead.

Once the information is available, how is it used?  We'd have to pass
additional information to the exec syscalls.  And it has to happen so
that if the exec call fails the original process is not affected (i.e.,
premature changing isn't an option).  The method also must be
thread-safe in a limited way: executing failing exec syscalls in
multiple threads mustn't disturb the process.

There is one set of problems which I don't care about but others likely
will: what happens if some program uses the syscalls directly?  And what
happens with old libcs and old statically linked programs?  It's exactly
the kind of problem why I tell people to never linked statically but
some people don't listen.

The additional file update check is hurting performance but since I hope
what we will get an inotify-like interface that doesn't need normal file
descriptors (or any file descriptors) I think I can live with it.
Somebody would "just" have to implement, e.g., the anonfd functionality
discussed some time ago.  (Make sure to talk to Al Viro who already
mentioned to me that it'll be "fun").

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkh2MSkACgkQ2ijCOnn/RHTepgCgrlkwQMItX2QGW6Tw//lw4vH2
ItIAoJ7qyQE31jpQ2D8fBIO/yqmrwgcH
=NQMC
-----END PGP SIGNATURE-----
--
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/