Bug 1717603 - Systemd doesn't allow to set User in service files to a username with a dot in it. Error: Invalid user/group name or numeric ID
Summary: Systemd doesn't allow to set User in service files to a username with a dot i...
Keywords:
Status: VERIFIED
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: systemd
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Jan Synacek
QA Contact: Frantisek Sumsal
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-05 19:14 UTC by Akshay Jain
Modified: 2020-02-28 12:52 UTC (History)
5 users (show)

Fixed In Version: systemd-239-20.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-18 10:18:19 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)

Description Akshay Jain 2019-06-05 19:14:23 UTC
Description of problem:
Systemd doesn't allow to set User in service files to a username with a dot in it.

Version-Release number of selected component (if applicable):
systemd-239-13.el8.x86_64
4.18.0-80.el8.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Create a test user as below

# useradd red.hat
# passwd red.hat


2. Create a test script as below

# vi /usr/lib/systemd/system/SMHI-startscript.service

[Unit]
Description=SMHI-startscript

After=network-online.target
Wants=network-online.target

[Service]
User=red.hat
Type=simple
ExecStart=/usr/bin/testsleep.sh

[Install]
WantedBy=multi-user.target


3. Reload systemd daemon to reflect the changes and start the service

# systemctl daemon-reload

# systemctl start SMHI-startscript.service

Actual results:

● SMHI-startscript.service - SMHI-startscript
   Loaded: bad-setting (Reason: Unit SMHI-startscript.service has a bad unit file setting.)
   Active: inactive (dead)

Jun 06 00:28:25 rhel8-12.gsslab.pnq2.redhat.com systemd[1]: /usr/lib/systemd/system/SMHI-startscript.service:14: Invalid user/group name or numeric ID: red.hat
Jun 06 00:28:30 rhel8-12.gsslab.pnq2.redhat.com systemd[1]: /usr/lib/systemd/system/SMHI-startscript.service:14: Invalid user/group name or numeric ID: red.hat
Jun 06 00:39:06 rhel8-12.gsslab.pnq2.redhat.com systemd[1]: /usr/lib/systemd/system/SMHI-startscript.service:14: Invalid user/group name or numeric ID: red.hat



Expected results:
# systemctl status SMHI-startscript.service
● test1.service - Test
   Loaded: loaded (/etc/systemd/system/SMHI-startscript.service; disabled; vendor preset: disabled)
   Active: active (exited) since Wed 2019-06-05 18:43:11 EDT; 2min 56s ago
  Process: 2126 ExecStart=/bin/bash /home/red.hat/test.sh (code=exited, status=0/SUCCESS)
 Main PID: 2126 (code=exited, status=0/SUCCESS)

Jun 05 18:43:10 localhost.localdomain systemd[1]: Starting SMHI-startscript...
Jun 05 18:43:11 localhost.localdomain systemd[1]: Started  SMHI-startscript...

Comment 1 Jan Synacek 2019-06-06 06:42:02 UTC
From my point of view, we should fix this.

https://github.com/systemd/systemd/issues/12754

Comment 2 Eric Söderman 2019-06-07 07:48:13 UTC
Thanks, would really like this to be fixed as it would give us problems otherwise as we use different .suffix for different user account types (production, test, dev etc).

Comment 3 Jan Synacek 2019-06-18 10:18:19 UTC
See the upstream issue.

Comment 4 adam winberg 2019-06-18 10:26:27 UTC
I'm wondering about this paragraph from upstream issue:

"Note that this restriction hsa been in place since a long long time in systemd, hence we don't even break compatibility here: it's not that we suddenly broke unit files that previously worked with systemd that no longer work."


This restriction is NOT in place in RHEL7, so for a RHEL customer this is a potentially breaking change (it is for us, causing a LOT of extra work to migrate to RHEL8). So, is a 'fix' for the rhel8 package really out of the question? 

A middle ground would be to make the behaviour configurable in systemd and thus leaving it to the user to decide.

Comment 5 Jan Synacek 2019-06-18 13:21:28 UTC
(In reply to adam winberg from comment #4)
> So, is a 'fix' for the rhel8 package really out of the question? 
> 
> A middle ground would be to make the behaviour configurable in systemd and
> thus leaving it to the user to decide.

I don't think it's out of the question, but I'm not willing to do another rhel-only patch. But the final decision is not mine. If you want, you can reopen this bugzilla so other members of the systemd team can give their opinions. I have already given mine, but the upstream disagrees.

As to the "middle ground", I don't think that there is one. We either enable the dot or not. Making it somehow configurable (compile time option? program argument?) would be way too complicated for what the functionality is supposed to be.

Comment 6 Akshay Jain 2019-07-04 17:22:05 UTC
As per my opinion , this is a must requirement . and we might expect alot of other customers to demand for the same.

If it is somehow possible to include this feature back, i am reopening this bugzilla, lets see if any other member has to say something on it.

Comment 7 Frantisek Sumsal 2019-08-28 15:26:51 UTC
The fix has been merged in upstream in https://github.com/systemd/systemd/pull/13244. There's also a commit (https://github.com/systemd/systemd/pull/13244/commits/88e2ed0b5bf6f08f5a2d4d64b1fefdc7192b9aac) which causes systemd to emit warning for usernames with a dot with them which should be, probably, discussed before backporting, as some customers may not like that.

Comment 8 Jan Synacek 2019-09-03 07:07:11 UTC
I suggest to allow the dot only, without the warning. The warning was an idiosyncratic decision, really.

Comment 10 Jan Synacek 2019-10-02 10:30:41 UTC
https://github.com/systemd-rhel/rhel-8/pull/25

Comment 12 Lukáš Nykrýn 2019-11-07 12:50:39 UTC
fix merged to github master branch -> https://github.com/systemd-rhel/rhel-8/pull/25 -> post


Note You need to log in before you can comment on or make changes to this bug.