[systemd-devel] sysusers and login.defs checks

[Simon McVittie]

On 23/07/14 19:50, Zbigniew Jędrzejewski-Szmek wrote:
>> As a side effect this would actually even allow us to be closer to
>> FEdora's current bheaviour, since it reserves UIDs < 200 for static
>> assignment, which we could then easily exclude from theis logic, too.
> In practice this might not be useful, because even if all the 800 UIDs
> starting from 999 were used up, it would be better to encroach on the
> "static" range than to fail.

At least in Debian and its derivatives, the statically-allocated ranges
0-99 and 60000-64999 are basically for two things: "well-known" users
like root/daemon/ftp/www-data, and packages that hard-code a numeric uid
at compile time. Yes, the latter is probably a design flaw in the
package that needs that uid[1]; but as long as such software exists,
installing it will result in it using that uid, whether it's already in
use by something else or not.

In this unlikely situation, it seems better to fail than to operate
insecurely; or if it's absolutely necessary to allocate a new dynamic
uid, taking one from the "real user" range seems less risky than taking
one from a statically-allocated range.

[1] arguably; iirc Apache suexec deliberately hard-codes www-data's uid
at compile time as a security measure, although that admittedly seems
more like security theatre than actual security, because if you can't
trust nsswitch then you've already lost