Hi,

Adam Borowski writes:

> On Tue, Jul 04, 2017 at 08:14:40PM +0900, Olaf Meeuwissen wrote:
>> Evilham writes:
>> > Hi there,
>> >

>> > Am 03/07/2017 um 16:08 schrieb dev:
>> >>   "So, yeah, I don't think there's anything to fix in systemd here."
>> >>    - Poettering

>> >>
>> >> Not sure what's more troubling here[1]; the lack of concern, the
>> >> digression from POSIX, or the bug/backdoor itself. Maybe all three.
>>
>> Indeed and that's exactly why systemd shouldn't assume it's living in a
>> Happy World of overly optimistic assumptions.
>>
>> > According to POSIX, a valid username may include: a-z, A-Z, 0-9, ., -, _
>> > Where "-" cannot appear at the beginning. There is no further
>> > restriction on the other chars.
>> > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_435
>>
>> So if systemd were to adhere to POSIX (now I'm being overly optimistic,
>> probably), systemd should check the user names in unit files for POSIX
>> conformance and flatly refuse to do anything if they're not.
>
> POSIX requires any system to accept _at_least_ this set of usernames.
> You are free to accept anything else. UTF-8 letters come to mind.

I mentioned that in my post as well. Here's wondering whether Shift-JIS
(unfortunately still prevalent in my neck of the woods) would fly.

> [~]# useradd блядь
> -- works ok.
>
> [~]# adduser блядь
> adduser: To avoid problems, the username should consist only of
> letters, digits, underscores, periods, at signs and dashes, and not start with
> a dash (as defined by IEEE Std 1003.1-2001). For compatibility with Samba
> machine accounts $ is also supported at the end of the username
>
> -- it adds @ anywhere and $ at the end.
>
>> If systemd were to just take any user name, then it should *still* check
>> that whatever user name it gets actuall corresponds to an existing user
>> (and that that user is a system user to boot) before going ahead and
>> doing anything.
>
> Why would running services be restricted to system users only?

I added that parenthetical because I thought Lennart mentioned something
about that in the GitHub issue. Thing is, if something is only supposed
to be run by a system user, systemd needs to make sure of that.

No idea whether systemd services run by non-system users makes sense but
then again, lots of systemd probably doesn't make much sense.

>> Of course, all this checking negatively affect boot times so systemd
>> simply assumes all's well ;-P
>
> The fun thing is, sysvinit tends to win in boot times for quite a margin.

Uhm, that was meant sarcastically. But you got that, right?

>> > So, useradd works because it's lower level, adduser does not, because it
>> > comes from shadow and they have more restrictions on what a valid name
>> > is. IMHO that's a bug in shadow.
>> > https://github.com/shadow-maint/shadow/blob/master/libmisc/chkname.c#L52
>>
>> On an even lower level, any text editor + shell combination will let you
>> add accounts with whatever whacky user name you can think of. As far as
>> /etc/passwd (and /etc/shadow) are concerned, the ':' is just about the
>> only character you cannot use file format wise. Whether login (or your
>> display manager) will let you login with that is another matter but for
>> systemd unit files the capability to login is not required.
>
> Well, and '\n'. But allowing '\n' in usernames would be about as bad an
> idea as allowing them in file names. And no one would be insane enough to
> do the latter, right? Right?

I wouldn't, not on purpose at least ;-) It has happened to me courtesy
of a bug in a script I wrote though.

> Another consideration is compatibility with AD+Samba. I'd find it
> repugnant to let a Windows machine provide security, but it's a quite
> widespread setup, which also allows usernames to start with a digit.
>
> A more -- heck, most -- important concern is that my usual secondary
> username is "1kb". Try to ban me and I'll bite. :þ
>
>> > It is not possible, for example to execute: adduser name.lastname, which
>> > is a valid POSIX username (but useradd name.lastname works fine).
>
> Banning a naming scheme this widespread means someone needs to get his head
> checked.

+1,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join