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.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.1 Date: Fri, 2 Oct 2020 14:58:57 +0200 From: Alexey Gladkov To: ALT Linux Team development discussions Message-ID: <20201002125857.y7p5ckbxjpjxvk6u@comp-core-i7-2640m-0182e6> 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> <20201002114645.GF1037402@cello> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5ypasnjot6mfnc6q" Content-Disposition: inline In-Reply-To: <20201002114645.GF1037402@cello> 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 12:59:06 -0000 Archived-At: List-Archive: List-Post: --5ypasnjot6mfnc6q Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 02, 2020 at 02:46:45PM +0300, Arseny Maslennikov wrote: > > > 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 obvi= ous 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. >=20 > That discussion then likely was not public; in part, that's why I'm askin= g. Yeah. Sometimes it happens. > > The > > idea was that the admin would prepare the system for use of cgroups by = the > > hasher-privd daemon. >=20 > 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. >=20 > Ok, this is a valid explanation and a valid feature. Thank you. Yes. This is an optional feature for the administrator. > > 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 me= an > > just hasher. >=20 > Subject: the future of hasher-privd >=20 > 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 -", ... At the time when I made this patch and thought in the future to try to make the hasher-privd more general-purpose. I had thoughts to add support for seccomp via the libkafel library, extend the use of namespaces (user, pid, time, etc). Another thought was not directly related to hasher-privd. I was thinking about trying to implement the creation of a chroot from docker images. > 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. The hasher-priv/hasher-privd has a global configuration. As long as different solutions are able to use it together, they can coexist. But this reuse of the server seems a little strange to me. > Or they wouldn't? Or a single hasher-privd instance =E2=80=94 aka node, a= ka main > process if you will =E2=80=94 would do both services? I don't yet have a = picture > of this in my head; this will have to be thought out. >=20 > Will the decoupled, generic hasher-privd have to expand its IPC API? I didn't expect the API to be public. I mean it will be used by someone other than the hasher-priv. I didn't think that far. I propose to postpone this question. We don't even have a server yet. > 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. Yep. When this happens, we will need to make a thoughtful public API. > 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. >=20 > In short, it's gonna be a long road. True. =20 > > With this in mind, I don't think that this server should do > > everything out of the box without configuration. >=20 > 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). I agree with you but let's not do it all at once. I have not been able to upstream the basic server implementation. I'm afraid more global changes will be accepted even slower. > 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 Rgrds, legion --5ypasnjot6mfnc6q Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQSuzIk+w2aWgaEZLHKOFEXcaOMeVAUCX3ckEQAKCRCOFEXcaOMe VDI6AJ9pzyDjvZ1Mi7kQztlCQvNnkrWdowCeKLbsSnzllSBipB8NzA9b1DFGD58= =Y6Ko -----END PGP SIGNATURE----- --5ypasnjot6mfnc6q--