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 54CBC138334 for ; Fri, 16 Aug 2019 22:40:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 13A46E08AD; Fri, 16 Aug 2019 22:40:50 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id ACE62E089F for ; Fri, 16 Aug 2019 22:40:49 +0000 (UTC) Received: from [192.168.1.100] (c-98-218-46-55.hsd1.md.comcast.net [98.218.46.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mjo) by smtp.gentoo.org (Postfix) with ESMTPSA id 073E5349C7B for ; Fri, 16 Aug 2019 22:40:47 +0000 (UTC) To: gentoo-dev@lists.gentoo.org From: Michael Orlitzky Subject: [gentoo-dev] RFC: GLEP81 home directory guidelines Message-ID: <1a2868d7-bd4b-cd8c-b51e-6fe994057540@gentoo.org> Date: Fri, 16 Aug 2019 18:40:32 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: bf3d56de-9104-4859-aa30-3753f769c82a X-Archives-Hash: fc55ac57cd92d9c1e156d13c882b08cf Pending https://github.com/gentoo/devmanual.gentoo.org/pull/99, I'd like to get something like this written down. Please give it a quick read and see if it makes sense, or if I've overlooked anything. Most of these would just be suggestions, to be implemented as post-install QA checks or repoman warnings. == Choosing a home directory == GLEP81 changed two aspects of user management: 1 Creating a user can now modify the permissions on an existing directory. Should the need arise, this is necessary for a new version of an acct-user package to be able to fix the ownership and permissions of its home directory 2 All user data aside from the username became non-local to ebuilds that depend on that user. This is merely a side-effect of moving the user creation out of the client package, and into a separate acct-user package. The first item means that you should be conservative when choosing a home directory. If at all possible, avoid choosing a home directory that is used by another package. In particular, no two acct-user packages should use the same home directory. At best, the ownership and permissions on a shared home directory would need to be kept synchronized between all packages that share it. At worst, if one package goes out-of-sync, it introduces a security hole for the other packages who no longer have the permissions they expect. The second item means that if your package requires a user, you can no longer be sure of that user's home directory or its ownership and permissions. If your package requires a directory to be owned and writable by some user, then your package's ebuild should create that directory and ensure that it is writable by the user. In other words, you should not rely on the directory being created "transitively," as one of your acct-user dependencies' home directories---because that home directory can change. These considerations motivate the following guidelines for GLEP81 home directories, all of which can be summarized as, ** If the default (empty) value of ACCT_USER_HOME will work, use it. ** Specifically, 1 Avoid using an ACCT_USER_HOME that belongs to another package. 2 No two acct-user packages should define the same ACCT_USER_HOME. 3 If your package's configuration needs to be able to write to e.g. /var/lib/, then your package's ebuild should create that directory and set its ownership and permissions. Barring any other considerations, the corresponding acct-user package should leave ACCT_USER_HOME at its default (empty) value; setting ACCT_USER_HOME=/var/lib/ would violate item (1). 4 Each user's home directory should be writable by that user. If it is not, that indicates that a shared and potentially sensitive location was chosen; and the fact that the home directory is not writable suggests that the default (empty) ACCT_USER_HOME would suffice instead. 5 As a corollary of the previous item, it is highly suspicious for an acct-user package to set ACCT_USER_HOME_OWNER="root:root". 6 The world-writable bit should never be set in ACCT_USER_HOME_PERMS. This would otherwise satisfy item (4), but should never be done for security reasons.