Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3947251pxj; Tue, 8 Jun 2021 02:41:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxdMxDO5fgvbEi5/7/xtzS7Lihkg5nnLoM78Qa4WEPA73FHvJAr65BOhvTi7MvnE0BRQiYS X-Received: by 2002:a17:906:988a:: with SMTP id zc10mr22124965ejb.62.1623145277075; Tue, 08 Jun 2021 02:41:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623145277; cv=none; d=google.com; s=arc-20160816; b=st401SEevc7B2cULDOSxTaS2FaHfz+nv6hVsc6H7BLEIbx5WHk44mKtyyX6Hbkf/cK 2gctO7ooRnBo5in9BS52tgstI8iR+6hPnMstUi7/wvKOQiMSeQCLGd2hLuS9G6WyNAz4 oLNf7yMs0UprTagjQiBByXmAhHWMqVYcxsEaEbNz9ZeoturMj9REwGKDjhUByqQH+tR5 xTgZjnIpBJhuibUTvZiEyxbIyft2iKdi7GKlL1GE7zdcfYRxLEqoSqHOP8HDs3p7dFc9 19rwc1C/Fxncr/dlBUwZhWd1c72wUCnWGm7wc+PmCgkWdAUJs+/t9VSVBI/BoG+BrIq5 OnwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :mime-version:user-agent:date:message-id:subject:from:to; bh=RuVXW7aZAeNqUb9lsYODMnqxXzMEHoKaRfWKCEURvqA=; b=tukSDly+SPJPzJFa8wJOrQw16raaeiH+JNsqgt+WfR7dwzw8lFGplkh+kbWoHd5hVW +mG336jCdPlMw99fLA7nI85Gxht+rLs+NYzslnXeuoxKnVrUseNV8i6F5GQenAOixhm2 egRt94sH5tPxSYZcdaD4XVFXLJmhjSfnjm3EBDHwjSawWa45hk69PEwC3i0zwUrSMjsb IfXg9DpHB50vrdSp6EGN7+53X12R56L1bVo+ApXONk0tcc5+Jh3kFRnEOQqgQ4xsjWTM /EnCuduzIlGsIMZnwtSk8nxpUsAUzUQLIGrpPdQuqqmIvB0QuKbHJfDcvQDpa0sUbdte WqeA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p19si14823289ejn.459.2021.06.08.02.40.53; Tue, 08 Jun 2021 02:41:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230017AbhFHJkO (ORCPT + 99 others); Tue, 8 Jun 2021 05:40:14 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:48001 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229507AbhFHJkO (ORCPT ); Tue, 8 Jun 2021 05:40:14 -0400 Received: from [192.168.1.155] ([77.7.0.189]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MjjGX-1l5cah3HQp-00lF5d; Tue, 08 Jun 2021 11:38:16 +0200 To: containers@lists.linux.dev, "linux-kernel@vger.kernel.org" From: "Enrico Weigelt, metux IT consult" Subject: device namespaces Message-ID: Date: Tue, 8 Jun 2021 11:38:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: tl Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:wxk78eUumZYNeOehK+YAmlLZTGCSWO3ghgFrKwZ1SPOQdNhz1ZM GdYoMpQoe+BAap7LC+pC5TIylANATBgsGirjYKOLa2T3RHdVDVaQo5MDPRa4bfw6TZBZoYY RaixW3pVbW/E7B8yip7Ewf+iU/8E/mUHbK15MJ0Gj2lVToUdRy05Gz6JYrNLH3omwp8Wcd4 FkmHUPW3SVrZn5lVIPzBg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Yp3wVbPV/tU=:pGuDUOoK8jP0HwtYX8i4be uUWOoaAGoKZ99Cv+ndQIbNm2sT7dXxR1/v3MqtYhONIki0ketzitptG77//X7N6vUI/bxiBEt lhiW59Y0By9FpnZCNgrQ3zDY5IB8z1RSFojKPUUAQ8KfsoKwwYcEgzvzBLex2vA1yAZBODBwl jJzJRhfAhAEs2TBs60PUC/Ivt/PDWIebjmAJQ2nIXzsHr0AXfg233ADLHnn3yc+/uqJUn+jWq acq8n+4V0OuQ8q4vtVQOqcXFyd2SnH9oKBTNFBoxLDZ9yUmcbVFYj3+C9dNGvTvJnXvgOIoJH jfX5zwD8vhHzt+NdtJKuCy2cWfrh041pAE3FNHVjIVpiZhx4iTvA9naR5D0jChfYyuNP79CxG QNIblvffwgNhKzlcOe84xR77hyzgkhwPWrjW2vJmYDULM8vV9UfenMzTClBvwsmrcKiMw5zua aCwS1QjC3J0q4HxqogmKE+zG59VjO8mQl12emcsWuNq0rPcsxx3vKenBnwLgL+9bsz3F/Xk5M Lza89StjjAenDPH11GF47I= Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello folks, I'm going to implement device namespaces, where containers can get an entirely different view of the devices in the machine (usually just a specific subset, but possibly additional virtual devices). For start I'd like to add a simple mapping of dev maj/min (leaving aside sysfs, udev, etc). An important requirement for me is that the parent ns can choose to delegate devices from those it full access too (child namespaces can do the same to their childs), and the assignment can change (for simplicity ignoring the case of removing devices that are already opened by some process - haven't decided yet whether they should be forcefully closed or whether keeping them open is a valid use case). The big question for me now is how exactly to do the table maintenance from userland. We already have entries in /proc//ns/*. I'm thinking about using them as command channel, like this: * new child namespaces are created with empty mapping * mapping manipulation is done by just writing commands to the ns file * access is only granted if the writing process itself is in the parent's device ns and has CAP_SYS_ADMIN (or maybe their could be some admin user for the ns ? or the 'root' of the corresponding user_ns ?) * if the caller has some restrictions on some particular device, these are automatically added (eg. if you're restricted to readonly, you can't give rw to the child ns). Is this a good way to go ? Or what would be a better one ? --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287