| 1 |
[2019-08-16 18:40:32-0400] Michael Orlitzky: |
| 2 |
> GLEP81 changed two aspects of user management: |
| 3 |
> |
| 4 |
> 1 Creating a user can now modify the permissions on an existing |
| 5 |
> directory. Should the need arise, this is necessary for a new |
| 6 |
> version of an acct-user package to be able to fix the ownership |
| 7 |
> and permissions of its home directory |
| 8 |
> |
| 9 |
> 2 All user data aside from the username became non-local to ebuilds |
| 10 |
> that depend on that user. This is merely a side-effect of moving |
| 11 |
> the user creation out of the client package, and into a separate |
| 12 |
> acct-user package. |
| 13 |
> |
| 14 |
> The first item means that you should be conservative when choosing a |
| 15 |
> home directory. If at all possible, avoid choosing a home directory |
| 16 |
> that is used by another package. In particular, no two acct-user |
| 17 |
> packages should use the same home directory. |
| 18 |
|
| 19 |
Any reason why sharing home directories isn't simply forbidden? |
| 20 |
This is sure to blow on us at some point if there is shared home directories. |
| 21 |
|
| 22 |
> 1 Avoid using an ACCT_USER_HOME that belongs to another package. |
| 23 |
> |
| 24 |
> 2 No two acct-user packages should define the same ACCT_USER_HOME. |
| 25 |
|
| 26 |
I feel like this is redundant, even if you would want to also cover |
| 27 |
pre-acct-user packages. |
| 28 |
|
| 29 |
> 3 If your package's configuration needs <username> to be able to |
| 30 |
> write to e.g. /var/lib/<username>, then your package's ebuild should |
| 31 |
> create that directory and set its ownership and permissions. Barring |
| 32 |
> any other considerations, the corresponding acct-user package should |
| 33 |
> leave ACCT_USER_HOME at its default (empty) value; setting |
| 34 |
> ACCT_USER_HOME=/var/lib/<username> would violate item (1). |
| 35 |
> |
| 36 |
> 4 Each user's home directory should be writable by that user. If it |
| 37 |
> is not, that indicates that a shared and potentially sensitive |
| 38 |
> location was chosen; and the fact that the home directory is not |
| 39 |
> writable suggests that the default (empty) ACCT_USER_HOME would |
| 40 |
> suffice instead. |
| 41 |
|
| 42 |
Shouldn't this be owned instead of writable? I'm pretty sure we can |
| 43 |
have cases where no having write permissions is prefered for security. |
| 44 |
|
| 45 |
> 5 As a corollary of the previous item, it is highly suspicious for |
| 46 |
> an acct-user package to set ACCT_USER_HOME_OWNER="root:root". |
| 47 |
|
| 48 |
Is there cases where this would be used? It makes no sense to me for a |
| 49 |
home to belong to root. |
Archives