From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 440351396D0 for ; Fri, 22 Sep 2017 15:06:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9D4671FC190; Fri, 22 Sep 2017 15:06:50 +0000 (UTC) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-oln040092003086.outbound.protection.outlook.com [40.92.3.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 36E7CE083E for ; Fri, 22 Sep 2017 15:06:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=m3sBVKZ48QNOv/2caht5XJgUKw0e9NIlgO7IY8uS4tE=; b=P5h9Vh3DYomFwg8xU/dUWRzuSxKvPgSsSMvV7vxR+Ex92SthaYiV4BaMOupjMGaAQvt+M3NagaOFjo+Sp6xRe1Mv6iXsuqVUJ0cJwhheWMaSdYtbdIrMBAS9qv1rZN+/PeW+WggX48UoFPqi3BWi4Q1a8ojxRipPYFj9ZJGeUPx0XEUQEDATBMJSYQIkV0YmBwRti/ZcbW5hI1TjkSgudn3QxMJpgauL8aHpAMCNnBNGsLR27sPvhaBAu4am8gnpUuLyCfkGripFFCUuPOm/jIHGYvPafO6VSIFSY7qvtyPGe/cY2TEiWCkzFomkPLybmhuISFXY1nOk22BHk1Ctag== Received: from CY1NAM02FT011.eop-nam02.prod.protection.outlook.com (10.152.74.57) by CY1NAM02HT193.eop-nam02.prod.protection.outlook.com (10.152.75.120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.35.14; Fri, 22 Sep 2017 15:06:49 +0000 Received: from MWHPR10MB1534.namprd10.prod.outlook.com (10.152.74.55) by CY1NAM02FT011.mail.protection.outlook.com (10.152.75.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.35.14 via Frontend Transport; Fri, 22 Sep 2017 15:06:49 +0000 Received: from MWHPR10MB1534.namprd10.prod.outlook.com ([10.169.235.10]) by MWHPR10MB1534.namprd10.prod.outlook.com ([10.169.235.10]) with mapi id 15.20.0077.011; Fri, 22 Sep 2017 15:06:49 +0000 From: James McMechan To: "gentoo-dev@lists.gentoo.org" Subject: Re: [gentoo-dev] Reviving the Sandbox project Thread-Topic: [gentoo-dev] Reviving the Sandbox project Thread-Index: AQHTMxO8r0tqU6xD/kSi3FI8WFQ39aK/y48AgAAF4wCAAAOwAIAABPOAgAAVSQCAAFsKAIAAcpGAgAALnACAAA2jgIAAIvL5 Date: Fri, 22 Sep 2017 15:06:49 +0000 Message-ID: References: <1506023769.15165.14.camel@gentoo.org> <1506025998.3293.1.camel@gentoo.org> <1506027262.15165.15.camel@gentoo.org> <1506028054.8561.1.camel@gentoo.org> <1506029117.15165.17.camel@gentoo.org> <1506053238.1115.0.camel@gentoo.org> <20170922125721.2fc2f243@gentoo.org> <20170922123854.179f605c@sf>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lists.gentoo.org; dkim=none (message not signed) header.d=none;lists.gentoo.org; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:0F1F8E75F4B093B72CA58CF73912F872F5486CB178E7F89C9171A564B5E35D5B;UpperCasedChecksum:8C5B8DAFF337F6940A6F4C257E0338C41391F55347BAE72EEC45971F13D59EB0;SizeAsReceived:7471;Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [9mFZ/3d33hHN+LS9C2IsVKYic0cnrw0e] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;CY1NAM02HT193;6:Wgk7qVPWkNA4OycNbdSinyPL4QXM+Y/pzC3ss3MJjdw0McA3BeuUwHgp1qW3YFQuwK3h8NzgrW72hDQfq6Au1IO+k/Wg7IluSyWlfxd5wlDGLrjRbRnIKrGNF9RxGrtd1WqTHRtyebX5oTaonYvPp5JGq0YftGaTu18j2MkX064D0nFc94dD2jJTPCc31H3H1zROkkRicJ9SGSRSPJeEI9apUIt3SBl/CJeljq2OMP8WWAe18yS4etp7JBcr6Nu7YNtXfE5kgmBPQQ6HHPwXhU0UThq+eLTSeffU/Xumb/dqASbnjGGMVbBYY8mDv4/nAwzofNew0XaB/Ko5ik6J0g==;5:HoY2HMKKCufKy9tEGAN9pzxqd4aF1r/9I5r+AaAGTU1zmRFfhuyKjWvgj0bINTQWnioXSKHpgjDM9tYSbsqVXCyuk6kn/nW20NG1aNT5Vu81YzF0m9X7NwBo7FJ6Xl0ujmp1HOmL+jFTm9hfydcV8Q==;24:DP9UIYoPUmErql6QnpFeBl9IokQXWaNLUnmFj+MB693oB2fiIEX+XLU50t1clSC7OYw85V9WIm/92e7ldhmXPz1cntXiQ3BfTkzjy3irq2E=;7:18GEWF7S+VVJGgobcUpsrbS5YerwKPcuB4uHGlAJuawErUMlLhj7+y7r3/raEYqLVBGNgF+Fk5rgA0E9I+4pYhDG1MJjsouJUQQng8Dx0HNEUbpb5M/bz8hDxxFyV4eK4aztj8OnT/z5n8+T5G0yitiyC3MWORIUlekooQfXwQt6zGOOSFhLNvNE5X9vhLy21ZSZqHHwU6Hdjv+RyrLtKAdoz5v3LTUSwH/3ofo9KRo= x-incomingheadercount: 46 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 9f7d0bdb-06d2-42a7-664c-08d501cb8ca3 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:CY1NAM02HT193; x-ms-traffictypediagnostic: CY1NAM02HT193: x-exchange-antispam-report-test: UriScan:(788757137089)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031);SRVR:CY1NAM02HT193;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:CY1NAM02HT193; x-forefront-prvs: 0438F90F17 x-forefront-antispam-report: SFV:NSPM;SFS:(7070007)(98901004);DIR:OUT;SFP:1901;SCL:1;SRVR:CY1NAM02HT193;H:MWHPR10MB1534.namprd10.prod.outlook.com;FPR:;SPF:None;LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2017 15:06:49.0582 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1NAM02HT193 X-Archives-Salt: 8201cd28-8067-449f-9884-516e7e47915b X-Archives-Hash: bd8c731e38cd5ad76511b318dc4004ff On Fri, Sep 22, 2017 at 5:27 AM, Rich Freeman wrote:=20 >On Fri, Sep 22, 2017 at 7:38 AM, Sergei Trofimovich wr= ote: >> >> Some other distros try harder to isolate build environment either >> through chroot and/or private mount/user/network namespace that >> contains only explicitly specified files in build environment. >> >> That would require more cooperation from package manager to fetch >> list of all visible depends. >> > >I definitely think this is something that would be VERY useful to >have, because it makes build-time dependency issues almost impossible. > >However, you don't need that complete solution just to have a sandbox. >You could simply create a container with the entire contents of the >main filesystem, but read-only, with the exception of the build area. >That would replicate the functionality of the current sandbox and >would be easier than building out just the files specified in the >dependencies. > >The main issue I see with making it dependency aware is performance. >You would need to walk all the dependencies and their run-time >dependencies, and the system set, and then individually bind-mount the >files that belong to them read-only into the container. That isn't >necessarily difficult, but I imagine that it would be slow. Walking >the dependencies obviously already happens during resolution so that >could probably be cached. You could also cache the list of files for >the system set, and you could even maintain a snapshot of these that >is used as the base of the container (somebody would need to work out >the savings of doing this vs the cost of updating it every time a >system set package changes). > >However, the main thing I wanted to point out is that you don't need a >dependency-aware solution to just replace the existing sandbox. > >> I like clear sandbox error reporting. > >As far as error reporting goes, you would get kernel-level errors like >attempting to write to a read-only bind mount, or trying to read a >file that doesn't exist. To a portage dev it should be pretty obvious >what is going on. You could add canned text to the portage error >output at the end. I'm not sure how visible the problems would be to >portage except to the degree that the build system makes them visible >- it would just see make terminate with a non-zero return. > >I would think that containers would be almost completely bug-free >though. The only thing I could see as an issue is some build system >that relies on IPC with the host, network access, etc. Namespaces >themselves are very robust, and the kernel already looks at every >process as belonging to a set of namespaces even in the default case >where you only have one set of namespaces on the system, so they don't >involve different code paths/etc. > >--=20 >Rich Another possibility, could be to have the sandbox be an overlayfs not of the build directory but of the entire system starting at "/" and sti= ck that into the container, only CLONE_NEWNS looks to be needed. A container with all writes going to the upper layer of the overlay could b= e safe against even #RM -RF / and other disasters, while still tracking what is happening during the build. Should performance be too much of a problem having a bind mount of the build directory on top of the overlay should give normal performance to everything that is obeying good practice. After the build completes the directory that was mounted as upper could be scanned to find any wayward writes that had occurred... This would not require LD_PRELOAD or ptrace eliminating most of the "high magic" currently used. Just yesterday I had a lot of ptrace failures while trying something odd with ROOT=3D and custom USE Jim McMechan=