| 1 |
GLEP 81 significantly changes the way that user management is handled, |
| 2 |
and reveals some subtle issues in existing packages that have remained |
| 3 |
hidden until now. Many of these issues can be avoided (in GLEP 81, but |
| 4 |
also in general) by exercising some discipline when choosing the data |
| 5 |
for new users and groups: |
| 6 |
|
| 7 |
* User and group names |
| 8 |
* Default shell |
| 9 |
* Home directory |
| 10 |
* Home directory ownership and permissions |
| 11 |
|
| 12 |
This commit adds a few new sections to the "Users and Groups" chapter |
| 13 |
that explain the current best practices, and give suggestions for |
| 14 |
choosing the user and group data listed above. The rationale for these |
| 15 |
choices is explained, and some notable exceptions are mentioned. |
| 16 |
--- |
| 17 |
ebuild-writing/users-and-groups/text.xml | 178 +++++++++++++++++++++++ |
| 18 |
1 file changed, 178 insertions(+) |
| 19 |
|
| 20 |
diff --git a/ebuild-writing/users-and-groups/text.xml b/ebuild-writing/users-and-groups/text.xml |
| 21 |
index 190a099..fca3959 100644 |
| 22 |
--- a/ebuild-writing/users-and-groups/text.xml |
| 23 |
+++ b/ebuild-writing/users-and-groups/text.xml |
| 24 |
@@ -103,6 +103,184 @@ The defaults are the user and primary group for the owner, and 0755 for the |
| 25 |
permissions. |
| 26 |
</p> |
| 27 |
|
| 28 |
+<important> |
| 29 |
+ Whenever possible, the default shell and home directory should be |
| 30 |
+ used. The rationale for this is explained below. |
| 31 |
+</important> |
| 32 |
+ |
| 33 |
+<p> |
| 34 |
+ You should embark upon a GLEP81 migration like an EAPI |
| 35 |
+ update. Rather than simply copy your user's settings into an |
| 36 |
+ <c>acct-user</c> package, you should take the opportunity to |
| 37 |
+ re-evaluate your user's name, shell, home directory, and its |
| 38 |
+ permissions. Our GLEP 81 implementation will reveal many user |
| 39 |
+ management issues that were allowed to fester in the past. |
| 40 |
+</p> |
| 41 |
+ |
| 42 |
+<subsection> |
| 43 |
+ <title>Choosing a shell</title> |
| 44 |
+ <body> |
| 45 |
+ <p> |
| 46 |
+ In most cases, the default shell (that is, no shell) should be |
| 47 |
+ used. Services can still be started as a user who has no shell, |
| 48 |
+ and daemons are able to drop privileges to a user who has no |
| 49 |
+ shell. If necessary, the administrator can override a user's |
| 50 |
+ default shell with <c>su -s <shell> |
| 51 |
+ <username></c>. This is sufficient for testing, management |
| 52 |
+ of SSH credentials, and for initial configuration in an ebuild's |
| 53 |
+ <c>pkg_config</c> phase. |
| 54 |
+ </p> |
| 55 |
+ <p> |
| 56 |
+ An obvious exception to this rule is if a human being will need |
| 57 |
+ to log into the account interactively, as is the case with the |
| 58 |
+ <c>root</c> user. Other exceptions certainly exist, but should |
| 59 |
+ be evaluated case-by-case. In other words, if you haven't |
| 60 |
+ checked, don't set your user's shell to <c>/bin/bash</c> because |
| 61 |
+ you think he <e>might</e> need it. |
| 62 |
+ </p> |
| 63 |
+ <p> |
| 64 |
+ The goal here is twofold. First, the principle of least |
| 65 |
+ privilege says that if a user doesn't need a real shell, he |
| 66 |
+ shouldn't have one. And along those same lines, not having a |
| 67 |
+ shell gives the system administrator some peace of mind: he |
| 68 |
+ doesn't have to be as concerned with whether or not that user |
| 69 |
+ has a password (and how strong it is), or whether or not its |
| 70 |
+ filesystem permissions are all set correctly, or whether or not |
| 71 |
+ it can log in via SSH, et cetera. |
| 72 |
+ </p> |
| 73 |
+ </body> |
| 74 |
+</subsection> |
| 75 |
+<subsection> |
| 76 |
+ <title>Choosing a home directory</title> |
| 77 |
+ <body> |
| 78 |
+ <p> |
| 79 |
+ In most cases, the default home directory (that is, no home |
| 80 |
+ directory) should be used. GLEP81 changed two aspects of user |
| 81 |
+ management with respect to home directories: |
| 82 |
+ </p> |
| 83 |
+ |
| 84 |
+ <ol> |
| 85 |
+ <li> |
| 86 |
+ Creating a user can now modify the permissions on an existing |
| 87 |
+ directory. Should the need arise, this is necessary for a new |
| 88 |
+ version of an <c>acct-user</c> package to be able to fix the |
| 89 |
+ ownership and permissions of its home directory. |
| 90 |
+ </li> |
| 91 |
+ <li> |
| 92 |
+ All user data aside from the username became non-local to |
| 93 |
+ ebuilds that depend on that user. This is merely a side-effect |
| 94 |
+ of moving the user creation out of the client package, and |
| 95 |
+ into a separate <c>acct-user</c> package. |
| 96 |
+ </li> |
| 97 |
+ </ol> |
| 98 |
+ |
| 99 |
+ <p> |
| 100 |
+ The first item means that you should be conservative when |
| 101 |
+ choosing a home directory. If at all possible, avoid choosing a |
| 102 |
+ home directory that is used by another package. In particular, |
| 103 |
+ no two <c>acct-user</c> packages should use the same home |
| 104 |
+ directory. At best, the ownership and permissions on a shared |
| 105 |
+ home directory would need to be kept synchronized between all |
| 106 |
+ packages that share it. At worst, one package goes out-of-sync |
| 107 |
+ and introduces a security hole for the others who no longer have |
| 108 |
+ the expected permissions. |
| 109 |
+ </p> |
| 110 |
+ |
| 111 |
+ <p> |
| 112 |
+ The second item means that if your package requires a user, you |
| 113 |
+ can no longer be sure of that user's home directory or its |
| 114 |
+ ownership and permissions. If your package requires a directory |
| 115 |
+ to be owned and writable by some user, then your package's |
| 116 |
+ ebuild should create that directory and ensure that it is |
| 117 |
+ writable by the user. In other words, you should not rely on the |
| 118 |
+ directory being created "transitively" by a dependency, even if |
| 119 |
+ that dependency is an <c>acct-user</c> package. |
| 120 |
+ </p> |
| 121 |
+ |
| 122 |
+ <p> |
| 123 |
+ In summary, |
| 124 |
+ </p> |
| 125 |
+ <ul> |
| 126 |
+ <li> |
| 127 |
+ Avoid using an <c>ACCT_USER_HOME</c> that belongs to another |
| 128 |
+ package. |
| 129 |
+ </li> |
| 130 |
+ <li> |
| 131 |
+ No two acct-user packages should define the same |
| 132 |
+ <c>ACCT_USER_HOME</c>. |
| 133 |
+ </li> |
| 134 |
+ |
| 135 |
+ <li> |
| 136 |
+ If for example your package's configuration needs |
| 137 |
+ <username> to be able to write to |
| 138 |
+ <c>/var/lib/<username></c>, then your package's ebuild |
| 139 |
+ should create that directory and set its ownership and |
| 140 |
+ permissions. Barring any other considerations, the |
| 141 |
+ corresponding <c>acct-user</c> package should leave |
| 142 |
+ <c>ACCT_USER_HOME</c> at its default (empty) value; setting |
| 143 |
+ <c>ACCT_USER_HOME=/var/lib/<username></c> creates |
| 144 |
+ unnecessary duplication and risks desynchronizing the |
| 145 |
+ permissions. |
| 146 |
+ </li> |
| 147 |
+ </ul> |
| 148 |
+ </body> |
| 149 |
+</subsection> |
| 150 |
+ |
| 151 |
+<subsection> |
| 152 |
+ <title>Choosing home directory ownership</title> |
| 153 |
+ <body> |
| 154 |
+ <p> |
| 155 |
+ In most cases, the default home directory ownership is correct. |
| 156 |
+ If a non-default home directory is needed at all, then it should |
| 157 |
+ be writable by its user and giving ownership of it to someone |
| 158 |
+ else would prevent that. Being unwritable indicates that a |
| 159 |
+ shared and potentially sensitive location was chosen. Moreover, |
| 160 |
+ the fact that the home directory is not writable suggests that |
| 161 |
+ the default home directory (which is also not writable) would |
| 162 |
+ suffice instead; the home directory guidelines explain why the |
| 163 |
+ default is preferable in that case. For example, setting |
| 164 |
+ <c>ACCT_USER_HOME_OWNER="root:root"</c> is suspicious because it |
| 165 |
+ appears intended to "undo" the ownership changed by your user |
| 166 |
+ package, and that would only be necessary if the path in |
| 167 |
+ question is used by some other package. |
| 168 |
+ </p> |
| 169 |
+ </body> |
| 170 |
+</subsection> |
| 171 |
+<subsection> |
| 172 |
+ <title>Choosing home directory permissions</title> |
| 173 |
+ <body> |
| 174 |
+ <p> |
| 175 |
+ In many cases, the default home directory permissions (0755) |
| 176 |
+ will suffice. But, if your package will work with mode 0700 or |
| 177 |
+ 0750, then those are preferable. This is the principle of least |
| 178 |
+ privilege again. If your package works with a non-writable home |
| 179 |
+ directory, then you should probably be using the default of |
| 180 |
+ <e>no</e> home directory! |
| 181 |
+ </p> |
| 182 |
+ <warning> |
| 183 |
+ The world-writable bit should never be set in |
| 184 |
+ <c>ACCT_USER_HOME_PERMS</c>. This should never be necessary, and |
| 185 |
+ is usually exploitable. |
| 186 |
+ </warning> |
| 187 |
+ </body> |
| 188 |
+</subsection> |
| 189 |
+ |
| 190 |
+<p> |
| 191 |
+ These suggestions are not rules and are not written in stone, except |
| 192 |
+ perhaps for the world-writable warning. There are packages in the |
| 193 |
+ tree that <c>chroot()</c> to <c>$HOME</c>, and require that |
| 194 |
+ directory to be owned by <c>root:root</c> for security reasons. In |
| 195 |
+ cases like that, it's impossible to avoid implicitly tying the user |
| 196 |
+ to the package that needs it via the home directory, and the best you |
| 197 |
+ can do is attempt to ensure that the users and paths are unique so |
| 198 |
+ that no conflicts arise. |
| 199 |
+</p> |
| 200 |
+ |
| 201 |
+<p> |
| 202 |
+ Unless your package is exceptional, though, following these |
| 203 |
+ guidelines will minimize the potential for problems down the |
| 204 |
+ road. |
| 205 |
+</p> |
| 206 |
</body> |
| 207 |
</section> |
| 208 |
|
| 209 |
-- |
| 210 |
2.21.0 |
Archives