From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29485 invoked from network); 15 Feb 2021 12:22:01 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 15 Feb 2021 12:22:01 -0000 Received: (qmail 11587 invoked by uid 89); 15 Feb 2021 12:22:25 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 11580 invoked from network); 15 Feb 2021 12:22:24 -0000 Date: Mon, 15 Feb 2021 12:21:56 +0000 From: Colin Booth To: supervision@list.skarnet.org Subject: Re: [s6-svperms] Handling service permissions at creation time. Message-ID: <20210215122156.GA22296@cathexis.xen.prgmr.com> References: <20210215133730.a09af2eda8df7b965188285f@obarun.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) On Mon, Feb 15, 2021 at 11:58:59AM +0000, Laurent Bercot wrote: > > So, If we have a e.g /data/perms/rules/uid//allow file and if s6-supervise check this directory at the creation time and create the necessary file/directory with the respective uid/gid found at that directory, we can configure a service permissions permanently. > > Typically, if you're using s6-rc, this can be done via a s6-rc > service running early, before the longruns are started. The "up" > script can read attributes from a file and set them; the "down" > script can save all the attributes to a file. > > Ideally, though, the user would be able to declare the attributes > in service definition directories, and s6-rc would set them > automatically at start. That wouldn't help with early services, but > early services should be few and far between and their permissions > shouldn't be trifled with. > > I can add that functionality to the next version of s6-rc. What do > you think? > Services can fix their own permissions so if s6-rc is going to grow that functionality it should be in the generated run, not in some rarely used outboard helper service. -- Colin Booth