From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=altlinux.org; s=dkim; h=Subject:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HCj1+ST64j+4CglkFhXAHIx8MODhSZ4kkCGc0SItvL8=; b=WwK9HdjLSV7irGxVBdG+8IVVoS +lQAWYVAxkj6dDog66lcU9hrv8iCfLHjTYx58U3qVawnmR0zHixQaRWWSvrg2lOQTccQR3mncnYjL ptBqhI/yixECzVv82BhUblkiwBESL2WK/y2NhQ8jc4Xd2My0fhAhUV26vnWT1yV7a87ohHiUZ6Bg3 RQFSuql/cGVYNqQv+/Nekg0C0NcF9fYOENOskZEdOnpvpTqNs5ywS06iWXI2W68zAMA0F+ThPHjt7 wSk98Kn+1uSAP6szeV5fBziMrMDJ0KxZRh7l2+DPLf0e6W9WVznHm1iUWcUtSygeNps0yd8bXQm+z px+iLhJQ==; Date: Fri, 2 Oct 2020 14:46:45 +0300 From: Arseny Maslennikov To: ALT Linux Team development discussions Message-ID: <20201002114645.GF1037402@cello> References: <2dd521b85103ae35347e548c89b6873a80811206.1576183643.git.legion@altlinux.org> <20200917131107.GE286846@cello> <20201001191733.tb5kgjn6ylpxlg5t@comp-core-i7-2640m-0182e6> <20201001202353.GC1037402@cello> <20201002004255.ejhzsfpaijn5yzxj@comp-core-i7-2640m-0182e6> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ULyIDA2m8JTe+TiX" Content-Disposition: inline In-Reply-To: <20201002004255.ejhzsfpaijn5yzxj@comp-core-i7-2640m-0182e6> OpenPGP: url=http://grep.cs.msu.ru/~ar/pgp-key.asc X-SA-Exim-Connect-IP: 37.204.119.143 X-SA-Exim-Mail-From: arseny@altlinux.org X-SA-Exim-Version: 4.2.1 X-SA-Exim-Scanned: Yes (on mail.cs.msu.ru) Cc: ldv@altlinux.org Subject: Re: [devel] [PATCH hasher-priv v1 3/3] Add cgroup support X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 11:46:50 -0000 Archived-At: List-Archive: List-Post: --ULyIDA2m8JTe+TiX Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 02, 2020 at 02:42:55AM +0200, Alexey Gladkov wrote: > On Thu, Oct 01, 2020 at 11:23:53PM +0300, Arseny Maslennikov wrote: > > > > Could you please explain what you're trying to do with this patch? > > > > Even if it's obvious from the source itself, we still must have an > > > > opportunity to discuss, and a decent explanation should stay in the > > > > project history. > > >=20 > > > I think this patch is simple enough. > >=20 > > There's a misunderstanding here. I'm not asking to explain the > > semantics (what this patch does) =E2=80=94 I repeat, it's rather obviou= s from > > the source itself, the patch is indeed simple. I'm trying to get how the > > patch's author would describe the pragmatic value of this patch. IOW: > > we see this patch does XXX. What, in Alexey's view, are we trying to > > achieve by implementing XXX? >=20 > I remember that this patch was the result of a discussion with ldv. That discussion then likely was not public; in part, that's why I'm asking. > I didn't want to add complex support for different versions of cgroups. I also believe that complexity would be unnecessary today. > The > idea was that the admin would prepare the system for use of cgroups by the > hasher-privd daemon. If I understood correctly ^U To put it another way, we're doing this because the machine admin might want hasher-privd to put the processes it spawns in cgroups _at_an_arbitrary_path_, at the administrator's discretion. Ok, this is a valid explanation and a valid feature. Thank you. Might not be fully implementable on systemd-based installations, though[1], but we'll look into it in time and work out something that fits everyone's varying needs and circumstances. I'm not yet sure from systemd's documentation if that program is OK with us making arbitrary cgroup trees _in_the_root_cgroup_. But we definitely can get a cgroup subtree to work in; this works. [1] https://systemd.io/CGROUP_DELEGATION/ >=20 > I'm not considering the hasher-privd as an end user server. This is a > low-level server on which you can build different solutions. I don't mean > just hasher. Subject: the future of hasher-privd I'm not particularly opposed to the expansion of hasher-privd's utility scope; there are quite a lot of potential use cases: hasher-privd as a general-purpose cgroup manager, hasher-privd as a daemon-based NO_NEW_PRIVS-ready policy-enforcing "su -", ... While this sounds interesting, I believe there are currently some obstacles. Would those solutions on top of hasher-privd be co-installable and co-existing on a single machine? E.g. two hasher-privd init scripts with different configuration files for different things, spawning different processes. Or they wouldn't? Or a single hasher-privd instance =E2=80=94 aka node, aka= main process if you will =E2=80=94 would do both services? I don't yet have a pi= cture of this in my head; this will have to be thought out. Will the decoupled, generic hasher-privd have to expand its IPC API? If we decouple hasher-privd from hasher, this would also mean we support arbitrary clients, so we'll have to formally define the IPC interface, see my concerns on it in a previous mail. As it stands now, the hasher project currently sees hasher-privd as its vital component, a specialized tool for a special purpose, configured at /etc/hasher-priv/. You're proposing something different. In short, it's gonna be a long road. > With this in mind, I don't think that this server should do > everything out of the box without configuration. I believe the hasher project _would_ want some sane out-of-the-box configuration. The generic privd you describe above might not, much like runc/crun do not, but the hasher project definitely would. Furthermore, in my personal (but shared by many) opinion, this hasher OOTB experience would have to be catered to the common case of an ALT Team developer, not to public builder services (which are already expected to take care to tune and harden their non-trivial configuration, and we can even ship recommendations for their use case in /usr/share/doc). The approach you suggest here could work, if e. g. the decoupled privd is shipped with no defaults, and the hasher project ships its own defaults for the desired operation of privd. >=20 > Does this make sense to you? Barring the questions raised above, it does, thank you. I'm just being thorough =3D) We still need to support every use case, and not forget anything. >=20 > > Descriptive commit messages are done (and are enforced in successful > > communities, e. g. LKML) for a reason. > >=20 > > The above essentially is my previous comment here, reworded and clarifi= ed. > >=20 > > If for some reason you believe it's shameful or rude to the community to > > "waste time" on textual explanations, fair enough =E2=80=94 I'll maybe = write a commit > > message myself (with my take on why this might be useful) and then most > > likely ACK the same patch, with authorship reattributed to you via From: > > in the patch body and the new commit message. Or else NAK this > > particular revision with an empty commit message and leave it up to > > ldv@. > > If it were up to me, I would not approve of empty commit messages in a > > lasting, crucial project like hasher-privd. People are forgetful, and > > commit messages exist to help. >=20 > Ok. >=20 > > > > Do we only support cgroup2 and ignore cgroup1? If yes, great, but > > > > perhaps then we might want to have a setting to not fiddle with cgr= oup > > > > trees, to support the unfortunate users that have to run Docker and > > > > other garbage. > > >=20 > > > Yeah, I didn't plan on supporting legacy version of cgroups. Docker > > > already can work with cgroupsv2. > >=20 > > Oh, I heard they were just recently working on cgroup2 support. >=20 > https://github.com/opencontainers/runc/blob/master/docs/cgroup-v2.md >=20 > --=20 > Rgrds, legion >=20 > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel --ULyIDA2m8JTe+TiX Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE56JD3UKTLEu/ddrm9dQjyAYL01AFAl93EyAACgkQ9dQjyAYL 01DQHg/+NxqCY1pBJpXtDACgnWUMGa/bGQFs/35y94xjVUgdkTXP5c04l6tg9YR9 TjaKL30ttsgcOLnrheW5Y6IoZlHROp3XO9R4fXC8agpD5Fj3CabtqkrHj+RjnJze wH5fEOn662Pywh0UBIfI7ibR4OvfBVuSZcK7K6C941zlAqHBq2J5XHQfD4TCs1xz zTqirpuRZu1vceLOQL6wSvZYSfeWF44C5uMwDiXMZf5FpgANsF4f600vbmi0UMW6 7v+M/FC63IYLovhfDkqnLfHgNM8BJzWk0WojTaQEvCyrNu31gRzpNkViZWdsGJ5I QjIuESbLS4NDPrcwn++m0iJIAGaOZ5g7oNkXhTsT3HEVuftm5TT75OEWPh4MEBrA lE15LohKqBV6o30SGcg5pTXwuPKEUNPLUZuZXbIIyR/W113frhTF8ECdCoAQPaUl 4kdZfasQVr1FOGTdRtPwtxA1imIIZWWrH9Eoaar6uf+LLZFmCAaRFJXjNCgNKnZF VMS5J2xtvaW77yavdkE7IL9dnTRdU9U1QTF2A7GNqyN4OUM9L2g3EKLwElpK67zd vaBB2xnMZfIs+plWRGnTLoajivxopOTppEzfhF9K+LHu8//PvdvlI3HVCq52LsRg ubRqLFvkxQLTIUgisPNXPp90Ua+RFy9ioiEpUnqXjfqgkEW28d0= =Uo7U -----END PGP SIGNATURE----- --ULyIDA2m8JTe+TiX--