Attachment #589602 for bug #693964




permissions.
</p>

<important>
Whenever possible, the default shell and home directory should be
used. The rationale for this is explained below.
</important>

<p>
You should embark upon a GLEP81 migration like an EAPI
update. Rather than simply copy your user's settings into an
<c>acct-user</c> package, you should take the opportunity to
re-evaluate your user's name, shell, home directory, and its
permissions. Our GLEP 81 implementation will reveal many user
management issues that were allowed to fester in the past.
</p>

<subsection>
<title>Choosing a shell</title>
<body>
<p>
In most cases, the default shell (that is, no shell) should be
used. Services can still be started as a user who has no shell, and
daemons are able to drop privileges to a user who has no shell. If
necessary, the administrator can override a user's default shell with
<c>su -s &lt;shell&gt; &lt;username&gt;</c>. This is sufficient for
testing, management of SSH credentials, and for initial configuration
in an ebuild's <c>pkg_config</c> phase.
</p>
<p>
An obvious exception to this rule is if a human being will need to log
into the account interactively, as is the case with the <c>root</c>
user. Other exceptions certainly exist, but should be evaluated
case-by-case. In other words, if you haven't checked, don't set your
user's shell to <c>/bin/bash</c> because you think he <e>might</e>
need it.
</p>
<p>
The goal here is twofold. First, the principle of least privilege says
that if a user doesn't need a real shell, he shouldn't have one. And
along those same lines, not having a shell gives the system
administrator some peace of mind: he doesn't have to be as concerned
with whether or not that user has a password (and how strong it is),
or whether or not its filesystem permissions are all set correctly, or
whether or not it can log in via SSH, et cetera.
</p>
</body>
</subsection>

<subsection>
<title>Choosing a home directory</title>
<body>
<p>
In most cases, the default home directory (that is, no home directory)
should be used. GLEP81 changed two aspects of user management with
respect to home directories:
</p>

<ol>
  <li>
    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 <c>acct-user</c> package to be able to fix the
    ownership and permissions of its home directory.
  </li>
  <li>
    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
    <c>acct-user</c> package.
  </li>
</ol>

<p>
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
<c>acct-user</c> 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, one
package goes out-of-sync and introduces a security hole for the others
who no longer have the expected permissions.
</p>
<p>
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" by a dependency, even if that dependency is an
<c>acct-user</c> package.
</p>
<p>
In summary,
</p>
<ul>
  <li>
    Avoid using an <c>ACCT_USER_HOME</c> that belongs to another
    package.
  </li>
  <li>
    No two acct-user packages should define the same
    <c>ACCT_USER_HOME</c>.
  </li>

  <li>
    If for example your package's configuration needs &lt;username&gt;
    to be able to write to <c>/var/lib/&lt;username&gt;</c>, then your
    package's ebuild should create that directory and set its
    ownership and permissions. Barring any other considerations, the
    corresponding <c>acct-user</c> package should leave
    <c>ACCT_USER_HOME</c> at its default (empty) value; setting
    <c>ACCT_USER_HOME=/var/lib/&lt;username&gt;</c> creates
    unnecessary duplication and risks desynchronizing the permissions.
  </li>
</ul>
</body>
</subsection>

<subsection>
<title>Choosing home directory ownership</title>
<body>
<p>
In most cases, the default home directory ownership is correct.  If a
non-default home directory is needed at all, then it should be
writable by its user and giving ownership of it to someone else would
prevent that. Being unwritable indicates that a shared and potentially
sensitive location was chosen. Moreover, the fact that the home
directory is not writable suggests that the default home directory
(which is also not writable) would suffice instead; the home directory
guidelines explain why the default is preferable in that case. For
example, setting <c>ACCT_USER_HOME_OWNER="root:root"</c> is suspicious
because it appears intended to "undo" the ownership changed by your
user package, and that would only be necessary if the path in question
is used by some other package.
</p>
</body>
</subsection>

<subsection>
<title>Choosing home directory permissions</title>
<body>
<p>
In many cases, the default home directory permissions (0755) will
suffice. But, if your package will work with mode 0700 or 0750, then
those are preferable. This is the principle of least privilege
again. If your package works with a non-writable home directory, then
you should probably be using the default of <e>no</e> home directory!
</p>
<warning>
The world-writable bit should never be set in
<c>ACCT_USER_HOME_PERMS</c>. This should never be necessary, and is
usually exploitable.
</warning>
</body>
</subsection>

<p>
These suggestions are not rules and are not written in stone, except
perhaps for the world-writable warning. There are packages in the tree
that <c>chroot()</c> to <c>$HOME</c>, and require that directory to be
owned by <c>root:root</c> for security reasons. In cases like that,
it's impossible to avoid implicitly tying the user to the package that
needs it via the home directory, and the best you can do is attempt to
ensure that the users and paths are unique so that no conflicts arise.
</p>

<p>
Unless your package is exceptional, though, following these guidelines
will minimize the potential for problems down the road.
</p>
</body>
</section>

- 

Return to bug 693964

Lines 103-108 The defaults are the user and primary group for the owner, and 0755 for the Link Here

(-)a/ebuild-writing/users-and-groups/text.xml (-1 / +169 lines)
103	permissions.	103	permissions.
104	</p>	104	</p>
105		105
		106	<important>
		107	Whenever possible, the default shell and home directory should be
		108	used. The rationale for this is explained below.
		109	</important>
		110
		111	<p>
		112	You should embark upon a GLEP81 migration like an EAPI
		113	update. Rather than simply copy your user's settings into an
		114	<c>acct-user</c> package, you should take the opportunity to
		115	re-evaluate your user's name, shell, home directory, and its
		116	permissions. Our GLEP 81 implementation will reveal many user
		117	management issues that were allowed to fester in the past.
		118	</p>
		119
		120	<subsection>
		121	<title>Choosing a shell</title>
		122	<body>
		123	<p>
		124	In most cases, the default shell (that is, no shell) should be
		125	used. Services can still be started as a user who has no shell, and
		126	daemons are able to drop privileges to a user who has no shell. If
		127	necessary, the administrator can override a user's default shell with
		128	<c>su -s <shell> <username></c>. This is sufficient for
		129	testing, management of SSH credentials, and for initial configuration
		130	in an ebuild's <c>pkg_config</c> phase.
		131	</p>
		132	<p>
		133	An obvious exception to this rule is if a human being will need to log
		134	into the account interactively, as is the case with the <c>root</c>
		135	user. Other exceptions certainly exist, but should be evaluated
		136	case-by-case. In other words, if you haven't checked, don't set your
		137	user's shell to <c>/bin/bash</c> because you think he <e>might</e>
		138	need it.
		139	</p>
		140	<p>
		141	The goal here is twofold. First, the principle of least privilege says
		142	that if a user doesn't need a real shell, he shouldn't have one. And
		143	along those same lines, not having a shell gives the system
		144	administrator some peace of mind: he doesn't have to be as concerned
		145	with whether or not that user has a password (and how strong it is),
		146	or whether or not its filesystem permissions are all set correctly, or
		147	whether or not it can log in via SSH, et cetera.
		148	</p>
		149	</body>
		150	</subsection>
		151
		152	<subsection>
		153	<title>Choosing a home directory</title>
		154	<body>
		155	<p>
		156	In most cases, the default home directory (that is, no home directory)
		157	should be used. GLEP81 changed two aspects of user management with
		158	respect to home directories:
		159	</p>
		160
		161	<ol>
		162	<li>
		163	Creating a user can now modify the permissions on an existing
		164	directory. Should the need arise, this is necessary for a new
		165	version of an <c>acct-user</c> package to be able to fix the
		166	ownership and permissions of its home directory.
		167	</li>
		168	<li>
		169	All user data aside from the username became non-local to ebuilds
170	that depend on that user. This is merely a side-effect of moving
171	the user creation out of the client package, and into a separate
172	<c>acct-user</c> package.
173	</li>
174	</ol>
175
176	<p>
177	The first item means that you should be conservative when choosing a
178	home directory. If at all possible, avoid choosing a home directory
179	that is used by another package. In particular, no two
180	<c>acct-user</c> packages should use the same home directory. At best,
181	the ownership and permissions on a shared home directory would need to
182	be kept synchronized between all packages that share it. At worst, one
183	package goes out-of-sync and introduces a security hole for the others
184	who no longer have the expected permissions.
185	</p>
186	<p>
187	The second item means that if your package requires a user, you can
188	no longer be sure of that user's home directory or its ownership and
189	permissions. If your package requires a directory to be owned and
190	writable by some user, then your package's ebuild should create that
191	directory and ensure that it is writable by the user. In other
192	words, you should not rely on the directory being created
193	"transitively" by a dependency, even if that dependency is an
194	<c>acct-user</c> package.
195	</p>
196	<p>
197	In summary,
198	</p>
199	<ul>
200	<li>
201	Avoid using an <c>ACCT_USER_HOME</c> that belongs to another
202	package.
203	</li>
204	<li>
205	No two acct-user packages should define the same
206	<c>ACCT_USER_HOME</c>.
207	</li>
208
209	<li>
210	If for example your package's configuration needs <username>
211	to be able to write to <c>/var/lib/<username></c>, then your
212	package's ebuild should create that directory and set its
213	ownership and permissions. Barring any other considerations, the
214	corresponding <c>acct-user</c> package should leave
215	<c>ACCT_USER_HOME</c> at its default (empty) value; setting
216	<c>ACCT_USER_HOME=/var/lib/<username></c> creates
217	unnecessary duplication and risks desynchronizing the permissions.
218	</li>
219	</ul>
220	</body>
221	</subsection>
222
223	<subsection>
224	<title>Choosing home directory ownership</title>
225	<body>
226	<p>
227	In most cases, the default home directory ownership is correct. If a
228	non-default home directory is needed at all, then it should be
229	writable by its user and giving ownership of it to someone else would
230	prevent that. Being unwritable indicates that a shared and potentially
231	sensitive location was chosen. Moreover, the fact that the home
232	directory is not writable suggests that the default home directory
233	(which is also not writable) would suffice instead; the home directory
234	guidelines explain why the default is preferable in that case. For
235	example, setting <c>ACCT_USER_HOME_OWNER="root:root"</c> is suspicious
236	because it appears intended to "undo" the ownership changed by your
237	user package, and that would only be necessary if the path in question
238	is used by some other package.
239	</p>
240	</body>
241	</subsection>
242
243	<subsection>
244	<title>Choosing home directory permissions</title>
245	<body>
246	<p>
247	In many cases, the default home directory permissions (0755) will
248	suffice. But, if your package will work with mode 0700 or 0750, then
249	those are preferable. This is the principle of least privilege
250	again. If your package works with a non-writable home directory, then
251	you should probably be using the default of <e>no</e> home directory!
252	</p>
253	<warning>
254	The world-writable bit should never be set in
255	<c>ACCT_USER_HOME_PERMS</c>. This should never be necessary, and is
256	usually exploitable.
257	</warning>
258	</body>
259	</subsection>
260
261	<p>
262	These suggestions are not rules and are not written in stone, except
263	perhaps for the world-writable warning. There are packages in the tree
264	that <c>chroot()</c> to <c>$HOME</c>, and require that directory to be
265	owned by <c>root:root</c> for security reasons. In cases like that,
266	it's impossible to avoid implicitly tying the user to the package that
267	needs it via the home directory, and the best you can do is attempt to
268	ensure that the users and paths are unique so that no conflicts arise.
269	</p>
270
271	<p>
272	Unless your package is exceptional, though, following these guidelines
273	will minimize the potential for problems down the road.
274	</p>
106	</body>	275	</body>
107	</section>	276	</section>
108		277
109	-