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=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.msu.ru; 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=OzZs9u7Pm/T5zGnQcfb6esYtYRMVrRDOjz+tuOFcy/w=; b=pKoHDopL9i86SbdkhduoDPSt59 YAC+LBHkcLZ5wSLPZqRYtZKzTD81GoaAhO/F7AckHCFjfMx2qv2XNq68JdzFcVbwmSmz5mF0Uu/WJ QQnyYPJoC2O8zpgo8qTxt+vvXJC/3B6Xr8s6Tw8qpw6j91Sm/rWoTBp7foQijXQ9Sup5p0+C7MkP0 IYNNZ3p/vg1mn7y5L0bNO7LrwhJrRPP0piCybcTJmNZf1GfEbFS5diXG0X0IF5ng2mvUeDvtSTChV J62kfnREfmMzHisReMrPBQkJNcyOi6byXm9g5CIj6BrhnSjqc4rw7nqXZ9EsO7PPk96senIyRNWi8 c8cZmpMg==; Date: Fri, 2 Oct 2020 00:24:09 +0300 From: Arseny Maslennikov To: ALT Linux Team development discussions Message-ID: <20201001212409.GD1037402@cello> References: <9bca7626b593f896de4283cba2d6290ec99eb4f2.1576183643.git.legion@altlinux.org> <20200917131013.GB286846@cello> <20201001194304.oktcp7jqmdgg34pn@comp-core-i7-2640m-0182e6> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hoZxPH4CaxYzWscb" Content-Disposition: inline In-Reply-To: <20201001194304.oktcp7jqmdgg34pn@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: ar@cs.msu.ru 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 1/3] Make a daemon from the hasher-priv 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: Thu, 01 Oct 2020 21:24:13 -0000 Archived-At: List-Archive: List-Post: --hoZxPH4CaxYzWscb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 01, 2020 at 09:43:04PM +0200, Alexey Gladkov wrote: > On Thu, Sep 17, 2020 at 04:10:13PM +0300, Arseny Maslennikov wrote: > > On Fri, Dec 13, 2019 at 12:42:03PM +0100, Alex Gladkov wrote: > > > From: Alexey Gladkov > > >=20 > > > All privileged operations moved to the daemon. Commands to the server > > > are sent through the unix domain socket. The credentials which the se= nder > > > specifies are checked by the kernel. The hasher-priv no longer SUID. > >=20 > > I'm going to suggest some English literacy/typo improvements in a separ= ate > > email. > >=20 > > >=20 > > > For each user server creates a separate session process that executes > > > commands only from the user who created it. The session process ends > >=20 > > Since that new process will still be privileged, why the additional fork > > and the new listening socket inode? Is the strive for less complex > > daemon source code the only driver for that, albeit a perfectly viable > > one? >=20 > We have privileged server. When a user request comes in a session daemon > is forked for him that opens a socket for such user. A separate process > is created for each job. If the session daemon is inactive, then after a > session_timeout it will terminate. Yes, this is well explained already. > This is done to isolate one user from > another. You cannot DoS the main server. So you mean resource exhaustion. What kind of resource? CPU time? A malicious client can uselessly connect to the main daemon, send IPC commands, get kicked, repeat. Open FDs come to mind. It makes sense for the main daemon to close the client connection after the serving "session" daemon spawn and the response; the main daemon probably already does, it should be obvious =66rom the patch. >=20 > > > after a certain period of inactivity. > >=20 > > No problem with that, but IMO we still should be careful > > about resource leaks. >=20 > The admin controls the number of users and hence the number of possible > session daemons. >=20 > > >=20 > >=20 > >=20 > >=20 > > > Signed-off-by: Alexey Gladkov > > > --- > > > hasher-priv/.gitignore | 1 + > > > hasher-priv/DESIGN | 281 ++++++++++++++++---------- > >=20 > > I'd like to see a formal description of the client-server protocol in e. > > g. hasher-priv/IPC, that shows the intended message exchanges and > > meanings. The message contents can be rather easily inferred from the C > > headers, but the semantics cannot. This ends up as a source of > > programming errors, see the other emails. > >=20 > > The relevant information is probably already present in the DESIGN file, > > but, as this is documentation for humans, we should wrap it into a form > > that's easier to comprehend without wasting much time. > >=20 > > I'm also worried about the message format using plain C ABI structs. > > We're not going to use it over the network on machines with different > > architectures, and we're never going to support a client and server from > > different package builds, sure. But is this enough of a justification? >=20 > Don't be fooled that a socket is being used. The hasher-provd will not be > able to work over the network. The file descriptors are passed over > the socket and privileges are checked. Yes, this was already well explained. Quote: >> We're not going to use it over the network on machines with different >> architectures, and we're never going to support a client and server from >> different package builds, sure. > <...> --hoZxPH4CaxYzWscb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE56JD3UKTLEu/ddrm9dQjyAYL01AFAl92SPQACgkQ9dQjyAYL 01D/UQ/+JFydLramRjWv+MaTpsYVng8N++IcQwA8QsjfPp+R+2K0o5fbpOE0WJN3 3bTqbhGizCyo8AoFbIBkZvRLEDFPELEeSChvkVeDDjbCjyzXfyGR/THgo1ICDUwh GrHHT1Pssqe5fJ7z14jHHXOXSNk+/M4xMq2s+YwNOZYZUkLpChEAfszhSlHYS9qp 4RXSf+SYTab4eFo2xfTjaGMjtVSlKDJyg/CF4axdUYnAKDVN7TULSg3bCSyvsMMI iJI9Hi/acoNTt/VLZe419tPPGuTIBcCH7X0yU7U0GOY/bvn4ES6bY63khTl9rrLb gDGLK8MVjOjvkIdD1RoTbycRaFd2oDHG5syGhK9cg0Au2uCLFhLMg2aBZGzLUUee zrniPJWvRkr0SI4NI8jx0vPTjmN/v6OwIcjjbVNAYk7HXwwPDeywGZsq/wVwtZB2 urD9DGRBHXBtbxTZmZ5bWDL8rS3lRdnEZTxqpyssLWWsah1HQzxQFyBP9Kn2iCws wFnaDeus06Y1YgoHNbKQbZYnM/NAG/t5XvgMmerFCZQAQgm5Wxgv/pxBDW37DIFo nokau4pgCHqAXxKvM2NRzNrTBscKUdwZzQ53z4d+/6tOUe3aL8BaPuquBmetjJ4Y nZigLVjts6msNUfjSjrWLAZJZvg5Jv9iMhefYdcC9kVXOXukPXs= =jT2B -----END PGP SIGNATURE----- --hoZxPH4CaxYzWscb--