Re: [systemd-devel] Github systemd issue 6237

[Michael Chapman]

On Thu, 6 Jul 2017, Zbigniew Jędrzejewski-Szmek wrote:

On Thu, Jul 06, 2017 at 01:43:32AM +0200, Reindl Harald wrote:

well, it even don't look but pretend it can't while it does which is
the worst type of operations possible - as long as "adduser" of the
underlying OS accepts and create "0pointer" systemd has *no business
at all* to pretend it can't


Then it's good the that it doesn't ;)

# adduser 0pointer

adduser: Please enter a username matching the regular expression configured
via the NAME_REGEX configuration variable.  Use the `--force-badname'
option to relax this check or reconfigure NAME_REGEX.


I know you really only brought this up to counter Reindl's comment, but I 
think it's important to point out that adduser's behaviour here is due to 
its default configuration -- not due to any fundamental "problems" with 
particular usernames. It's not clear why adduser's developers thought it 
was a good default.


I guess what I'm saying is that saying "systemd should not support 
usernames that start with a digit, since adduser doesn't" is problematic 
for at least two reasons. First, adduser can be reconfigured by the 
sysadmin to allow such usernames; and second, systemd places *fewer* 
restrictions on usernames than adduser's default configuration. systemd 
allows usernames containing uppercase letters and underscores, for 
instance.


To summarize my thoughts on this matter, I think it's fine to restrict 
usernames, but only for _very_ good reason. Specifically, we should not 
justify such restrictions simply because they exist in one form or another 
in other utilities. valid_user_group_name() currently disallows dots, for 
instance, and while I recognize that using dots in a username can 
sometimes be problematic, it is not in and of itself invalid. If other 
software can't handle dots in usernames, that's their problem. libc can, 
and that's all that's required to support it in order to use it in User= 
on most systems.


But whether or not usernames are restricted, it's very important to alert 
the sysadmin to the fact their unit file isn't being interpreted the way 
they wrote it.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Github systemd issue 6237

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jul 06, 2017 at 01:43:32AM +0200, Reindl Harald wrote:
> 
> 
> Am 06.07.2017 um 01:36 schrieb Michael Chapman:
> >Note that the semantic validations you're talking about here --
> >things like "does the user exist?" -- are _not_ preemptive. They
> >are fatal: the child process will exit unsuccessfully as the
> >command is executed if the settings will not be able to be
> >applied.
> >
> >User=0day fails a syntactic validation, not a semantic validation.
> >systemd never even checks to see whether the user exists when the
> >unit is loaded. And nor should it! The user must be allowed to not
> >exist at unit-load time.
> >
> >Contrary to some of the comments in this thread, there is no point
> >in systemd's operation where it goes "oh look, that user actually
> >exists but I'm going to pretend it doesn't"
> 
> well, it even don't look but pretend it can't while it does which is
> the worst type of operations possible - as long as "adduser" of the
> underlying OS accepts and create "0pointer" systemd has *no business
> at all* to pretend it can't

Then it's good the that it doesn't ;)

# adduser 0pointer

adduser: Please enter a username matching the regular expression configured
via the NAME_REGEX configuration variable.  Use the `--force-badname'
option to relax this check or reconfigure NAME_REGEX.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Github systemd issue 6237

[Reindl Harald]

Am 06.07.2017 um 01:36 schrieb Michael Chapman:
Note that the semantic validations you're talking about here -- things 
like "does the user exist?" -- are _not_ preemptive. They are fatal: the 
child process will exit unsuccessfully as the command is executed if the 
settings will not be able to be applied.


User=0day fails a syntactic validation, not a semantic validation. 
systemd never even checks to see whether the user exists when the unit 
is loaded. And nor should it! The user must be allowed to not exist at 
unit-load time.


Contrary to some of the comments in this thread, there is no point in 
systemd's operation where it goes "oh look, that user actually exists 
but I'm going to pretend it doesn't"


well, it even don't look but pretend it can't while it does which is the 
worst type of operations possible - as long as "adduser" of the 
underlying OS accepts and create "0pointer" systemd has *no business at 
all* to pretend it can't

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Github systemd issue 6237

[Michael Chapman]

On Thu, 6 Jul 2017, Felipe Sateler wrote:

On Tue, 04 Jul 2017 18:39:15 +, Zbigniew Jędrzejewski-Szmek wrote:


Essentially, User=0day is the same as Usre=0day and the same as User="my
name is pretty!".


I think this is the root of the disagreement. Systemd tries to allow
units written for version X to run on versions earlier than X. I think
that is a good idea, and I don't think anyone is claiming it isn't. Which
is why invalid lvalues should be warned about but ignored, and I don't
think anyone is disputing this.

OTOH, invalid rvalues are a different thing: systemd recognizes the
setting it is trying to apply, but it can't. I think the argument that
systemd should fail the unit here is strong. Or at least for a certain
subset of the settings.



I do agree that we might want to completely reject unit files when some
crucial lines fail to parse, for example ExecStart or WorkingDirectory
or User, but it's not as obvious as one would think at first.


Indeed. Marking invalid rvalues as failing the unit does bring backwards-
compatibility issues. Suppose systemd X+1 adds a new @ shortcut for
SystemCallFilter: should systemd X fail a unit that uses it? The problem
would be the same as with User=0day, as the service would run with higher
privileges than expected.

A possibility would be to make systemd have its preemptive validations[1]
be fatal. Setting `User=idontexist` would then be equal to `User=whoa!`,
because neither of the usernames (should) exist.

[1] That is, validations for things it does not control itself. systemd
does not control the username format, the uid range, allowed directories,
etc, but rather validates against an external standard. That is, assume
that things that don't validate would fail at application time with a non-
ignorable EINVAL. This is different from things it defines itself, such
as @ settings for SystemCallFilter.


Note that the semantic validations you're talking about here -- things 
like "does the user exist?" -- are _not_ preemptive. They are fatal: the 
child process will exit unsuccessfully as the command is executed if the 
settings will not be able to be applied.


User=0day fails a syntactic validation, not a semantic validation. systemd 
never even checks to see whether the user exists when the unit is loaded. 
And nor should it! The user must be allowed to not exist at unit-load 
time.


Contrary to some of the comments in this thread, there is no point in 
systemd's operation where it goes "oh look, that user actually exists but 
I'm going to pretend it doesn't".___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Github systemd issue 6237

[Reindl Harald]

Am 05.07.2017 um 20:34 schrieb Jonathan de Boyne Pollard:

Reindl Harald:


at least fall back to "nobody"


That idea is wrong.

https://news.ycombinator.com/item?id=14681377#14682059


better than a stupid "i fall back to root because i think i make the 
rules and not the underlying operating system where this user in fact 
exists"

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Github systemd issue 6237

[Jonathan de Boyne Pollard]

Reindl Harald:

> 
> at least fall back to "nobody"
> 

That idea is wrong.

https://news.ycombinator.com/item?id=14681377#14682059___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] mkosi.postinst and user home permissions

[Federico Bruni]

Il giorno mer 5 lug 2017 alle 11:51, Federico Bruni 
 ha scritto:



Il giorno mar 4 lug 2017 alle 12:28, Federico Bruni 
 ha scritto:

Hi all

I hope this is the right place to ask questions about mkosi.
If not, please advise where I should ask.

I'm building fedora-26 in a directory.
I want to add a normal user, so I've added to mkosi.postinst:

useradd dev -p mypassword
usermod dev -a -G wheel

These two commands work fine, but the permissions are not correct:

# ls -l /home/
total 4
drwxrwxr-x 2 root root 4096 Jul  3 18:13 dev

Is this a bug? Or maybe what I'm trying to do should be accomplished 
in another way?

As a workaround, I might try add a third line to mkosi.postinst:

chown -R dev:dev /home/dev




Further to above, there are more problems:

- files in /etc/skel were not copied in /home/dev
- dev user password is not saved in /etc/passwd, so I cannot log in 
with that user


These problems do not occur if I create an user within the container:

# useradd test -p testing!
# ls -a /home/test/
.  ..  .bash_logout  .bash_profile  .bashrc
# ls -l /home
drwx-- 2 test test 4096 Jul  5 11:45 test

So it's not a bug in shadow-utils.
It must be something about how mkosi.postinst work. Unfortunately I 
don't have any mkosi examples to look at, in order to find any easy 
mistake I might have done.




Ok, problem found: I put a file in mkosi.extra/home/dev instead of 
mkosi.extra/etc/skel.
mkosi first copied that file, then launched the postinst script with 
the useradd command, which warned (correctly) that /home/dev already 
existed.


Sorry for the noise





___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bouncing interface once chrony is synced

[Reindl Harald]

Am 05.07.2017 um 17:29 schrieb Ian Pilcher:

I am using CentOS 7 (systemd 219) on a Banana Pi as my residential
firewall/gateway.  The Banana Pi does not have a persistent clock, so
it has no idea what the time is until it is able to sync via NTP.  Thus,
the initial DHCP leases that the BPi receives have incorrect expiration/
renewal times (since the system can't sync via NTP before it has an IP
address - chicken and egg).

My first attempt to address this was to add a drop-in to
chrony-wait.service that bounces the WAN interface.

Unfortunately, the expected dhclient processes are not running, so the
addresses are never renewed.  I suspect that systemd may be killing
them, because chrony-wait is a oneshot service.

Can anyone suggest a way to achieve this?


by just doing the dhcpd stuff on your own, do what ever you need 
"oneshot" in ExecStartPre/ExecStartPost and put the dchclient into 
ExecStart of a Type=forking unit


s[root@srv-rhsoft:~]$ systemctl status network-wan-bridge.service
? network-wan-bridge.service - Network Internet Bridge
   Loaded: loaded (/etc/systemd/system/network-wan-bridge.service; 
enabled; vendor preset: disabled)

   Active: active (running) since Di 2017-07-04 08:47:33 CEST; 1 day 8h ago
 Main PID: 8182 (dhclient)
Tasks: 1 (limit: 512)
   CGroup: /system.slice/network-wan-bridge.service
   ??8182 /usr/sbin/dhclient -4 -H srv-rhsoft -q 
--request-options subnet-mask,broadcast-address,routers,interface-mtu br-wan


Warning: Journal has been rotated since unit was started. Log output is 
incomplete or unavailable.

[root@srv-rhsoft:~]$ cat /etc/systemd/system/network-wan-bridge.service
[Unit]
Description=Network Internet Bridge
After=network.service systemd-networkd.service network-online.target

[Service]
Type=forking
ExecStartPre=-/usr/sbin/brctl addbr br-wan
ExecStartPre=-/usr/sbin/brctl stp br-wan off
ExecStartPre=-/usr/sbin/brctl setageing br-wan 600
ExecStartPre=-/usr/sbin/brctl setfd br-wan 5
ExecStartPre=-/usr/sbin/brctl addif br-wan wan
ExecStartPre=-/usr/sbin/brctl addif br-wan vmnet1
ExecStartPre=-/usr/sbin/ifconfig br-wan hw ether 00:50:8D:B5:CC:DE up
ExecStart=/usr/sbin/dhclient -4 -H srv-rhsoft -q --request-options 
subnet-mask,broadcast-address,routers,interface-mtu br-wan

ExecStartPost=-/usr/sbin/ifconfig br-wan -multicast -allmulti
ExecStartPost=-/usr/sbin/ifconfig vmnet1 0.0.0.0 -multicast -allmulti up
ExecStopPost=-/usr/sbin/ifconfig br-wan down
ExecStopPost=-/usr/sbin/brctl delbr br-wan

Restart=always
RestartSec=1

PrivateTmp=yes
NoNewPrivileges=yes
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE 
CAP_NET_BROADCAST CAP_NET_RAW
SystemCallFilter=~acct modify_ldt add_key adjtimex clock_adjtime 
delete_module fanotify_init finit_module get_mempolicy init_module 
io_destroy io_getevents iopl ioperm io_setup io_submit io_cancel kcmp 
kexec_load keyctl lookup_dcookie mbind migrate_pages mount move_pages 
open_by_handle_at perf_event_open pivot_root process_vm_readv 
process_vm_writev ptrace remap_file_pages request_key set_mempolicy 
swapoff swapon umount2 uselib vmsplice 





ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr

InaccessibleDirectories=-/mnt
InaccessibleDirectories=-/mnt/data
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Bouncing interface once chrony is synced

[Ian Pilcher]

I am using CentOS 7 (systemd 219) on a Banana Pi as my residential
firewall/gateway.  The Banana Pi does not have a persistent clock, so
it has no idea what the time is until it is able to sync via NTP.  Thus,
the initial DHCP leases that the BPi receives have incorrect expiration/
renewal times (since the system can't sync via NTP before it has an IP
address - chicken and egg).

My first attempt to address this was to add a drop-in to
chrony-wait.service that bounces the WAN interface.

  /etc/systemd/system/chrony-wait.service.d/bounce-wan.conf:

# Bounce the WAN interface once time is synced, ensuring that
# DHCP leases have proper expiration/refresh times.

[Service]
ExecStartPost=/usr/sbin/ifdown eth0.256
ExecStartPost=/usr/sbin/ifup eth0.256

This does bounce the interface at boot time:

  Dec 31 18:00:18 firewall.penurio.us systemd[1]: Starting Wait for 
chrony to synchronize system clock...
  Jul 04 13:05:07 firewall.penurio.us dhclient[1336]: DHCPDISCOVER on 
eth0.256 to 255.255.255.255 port 67 interval 8 (xid=0x38c8bfa7)
  Jul 04 13:05:07 firewall.penurio.us dhclient[1336]: DHCPREQUEST on 
eth0.256 to 255.255.255.255 port 67 (xid=0x38c8bfa7)
  Jul 04 13:05:07 firewall.penurio.us dhclient[1336]: DHCPOFFER from 
70.119.128.1
  Jul 04 13:05:07 firewall.penurio.us dhclient[1336]: DHCPACK from 
70.119.128.1 (xid=0x38c8bfa7)
  Jul 04 13:05:10 firewall.penurio.us dhclient[1336]: bound to 
70.119.136.2 -- renewal in 23274 seconds.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: PRC: Previous 
lease is devoid of active addresses.  Re-initializing.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: XMT: Solicit on 
eth0.256, interval 1010ms.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: RCV: Advertise 
message on eth0.256 from fe80::201:5cff:fe77:bc46.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: XMT: Request on 
eth0.256, interval 940ms.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: RCV: Advertise 
message on eth0.256 from fe80::201:5cff:fe77:bc46.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: Packet received, 
but nothing done with it.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: RCV: Reply 
message on eth0.256 from fe80::201:5cff:fe77:bc46.
  Jul 04 13:05:20 firewall.penurio.us systemd[1]: Started Wait for 
chrony to synchronize system clock.


Unfortunately, the expected dhclient processes are not running, so the
addresses are never renewed.  I suspect that systemd may be killing
them, because chrony-wait is a oneshot service.

Can anyone suggest a way to achieve this?

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Github systemd issue 6237

[Felipe Sateler]

On Tue, 04 Jul 2017 18:39:15 +, Zbigniew Jędrzejewski-Szmek wrote:

> Essentially, User=0day is the same as Usre=0day and the same as User="my
> name is pretty!".

I think this is the root of the disagreement. Systemd tries to allow 
units written for version X to run on versions earlier than X. I think 
that is a good idea, and I don't think anyone is claiming it isn't. Which 
is why invalid lvalues should be warned about but ignored, and I don't 
think anyone is disputing this.

OTOH, invalid rvalues are a different thing: systemd recognizes the 
setting it is trying to apply, but it can't. I think the argument that 
systemd should fail the unit here is strong. Or at least for a certain 
subset of the settings.

> 
> I do agree that we might want to completely reject unit files when some
> crucial lines fail to parse, for example ExecStart or WorkingDirectory
> or User, but it's not as obvious as one would think at first.

Indeed. Marking invalid rvalues as failing the unit does bring backwards-
compatibility issues. Suppose systemd X+1 adds a new @ shortcut for 
SystemCallFilter: should systemd X fail a unit that uses it? The problem 
would be the same as with User=0day, as the service would run with higher 
privileges than expected.

A possibility would be to make systemd have its preemptive validations[1] 
be fatal. Setting `User=idontexist` would then be equal to `User=whoa!`, 
because neither of the usernames (should) exist.

[1] That is, validations for things it does not control itself. systemd 
does not control the username format, the uid range, allowed directories, 
etc, but rather validates against an external standard. That is, assume 
that things that don't validate would fail at application time with a non-
ignorable EINVAL. This is different from things it defines itself, such 
as @ settings for SystemCallFilter.


-- 
Saludos,
Felipe Sateler

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] rules: block - add dm devices to whitelist

[David Disseldorp]

Ceph relies on by-partuuid symlinks, in order to locate the journal
partition from a given OSD partition. For details, see
http://tracker.ceph.com/issues/19489.
---
 rules/60-persistent-storage.rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rules/60-persistent-storage.rules 
b/rules/60-persistent-storage.rules
index 5ab03fc27..bc0721f32 100644
--- a/rules/60-persistent-storage.rules
+++ b/rules/60-persistent-storage.rules
@@ -6,7 +6,7 @@
 ACTION=="remove", GOTO="persistent_storage_end"
 
 SUBSYSTEM!="block", GOTO="persistent_storage_end"
-KERNEL!="loop*|mmcblk*[0-9]|msblk*[0-9]|mspblk*[0-9]|nvme*|sd*|sr*|vd*|xvd*|bcache*|cciss*|dasd*",
 GOTO="persistent_storage_end"
+KERNEL!="loop*|mmcblk*[0-9]|msblk*[0-9]|mspblk*[0-9]|nvme*|sd*|sr*|vd*|xvd*|bcache*|cciss*|dasd*|dm*",
 GOTO="persistent_storage_end"
 
 # ignore partitions that span the entire disk
 TEST=="whole_disk", GOTO="persistent_storage_end"
-- 
2.12.3

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Github systemd issue 6237

[Reindl Harald]

Am 05.07.2017 um 12:32 schrieb Michael Chapman:

In Wed, 5 Jul 2017, Reindl Harald wrote:

 The issue being discussed here is that systemd considers "0day" to be
 _syntactically_ invalid for a username. See the valid_user_group_name()
 function in basic/user-util.c.


yes and hence it should FAIL the service and not behave silently like 
the left side of a param is unknown on a older version - a invalid 
VALUE in a config has to fail until it's makred with a dash to silent 
be ignored in case of errors


That's really not what the dash means.

In the various Exec*= directives, a dash means that the command is 
allowed to fail. Similarly, in WorkingDirectory= the dash means the 
directory need not exist.


I do not believe there are any cases where a dash is used to side-step 
_syntactic_ validation, nor do I think there should be.


Really, you should just think of the dashes as being part of the syntax 
for the directives that support them.


As far as directives like User= go, there _may_ be a use for dash to 
mean "do not change UIDs if the username turns out to not actually 
exist"... but I would strongly advise against it


better than silently ignore a directive and run code as root which was 
never intended to run as root because of questionable "we know better 
what is valid then the underlying system which allowed to create that 
user" - do it proper or fail but not start code as root and pretend you 
are right


such issues closed as "not a bug" as well as 
https://github.com/systemd/systemd/issues/5644 with comments like "Yeah, 
it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, 
no?" which is not true for years make me afraid because it is a "to 
begin with we are always right" attitude

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Github systemd issue 6237

[Michael Chapman]

In Wed, 5 Jul 2017, Reindl Harald wrote:



Am 05.07.2017 um 12:10 schrieb Michael Chapman:

 On Wed, 5 Jul 2017, Colin Guthrie wrote:
>  Reindl Harald wrote on 04/07/17 19:50:
> > >  When new configuration options are added, the same unit file can
> > >  almost always be used with older systemd, and it'll just warn & 
> > >  ignore

> > >  the parts it doesn't understand. Similarly, various configuration
> > >  options might be unavailable on some architectures and with some
> > >  compilation options. The current behaviour of warn provides
> > >  for "soft degradation" in those cases.
> > 
> >  frankly a new option on the left side is a completly different thing

> >  than a invalid value - just silently continue with invalid values of
> >  existing options is playing a danergous game in a crucial component 
> >  like

> >  systemd
> 
>  It's a rare thing :p but I have to agree with you here!
> 
>  I'd say if "User=-notauser" then silently failing and using root is

>  acceptable as per the usual semantics of "- prefix suppresses errors",
>  but "User=notauser" should fail IMO.

 I'm pretty sure you'll find that it does. Specifically, it will fail when
 the child process for the command being executed attempts to map the
 username to a UID.

 The issue being discussed here is that systemd considers "0day" to be
 _syntactically_ invalid for a username. See the valid_user_group_name()
 function in basic/user-util.c.


yes and hence it should FAIL the service and not behave silently like the 
left side of a param is unknown on a older version - a invalid VALUE in a 
config has to fail until it's makred with a dash to silent be ignored in case 
of errors


That's really not what the dash means.

In the various Exec*= directives, a dash means that the command is allowed 
to fail. Similarly, in WorkingDirectory= the dash means the directory need 
not exist.


I do not believe there are any cases where a dash is used to side-step 
_syntactic_ validation, nor do I think there should be.


Really, you should just think of the dashes as being part of the syntax 
for the directives that support them.


As far as directives like User= go, there _may_ be a use for dash to mean 
"do not change UIDs if the username turns out to not actually exist"... 
but I would strongly advise against it.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Github systemd issue 6237

[Michael Chapman]

On Wed, 5 Jul 2017, Colin Guthrie wrote:

Reindl Harald wrote on 04/07/17 19:50:

When new configuration options are added, the same unit file can
almost always be used with older systemd, and it'll just warn & ignore
the parts it doesn't understand. Similarly, various configuration
options might be unavailable on some architectures and with some
compilation options. The current behaviour of warn provides
for "soft degradation" in those cases.


frankly a new option on the left side is a completly different thing
than a invalid value - just silently continue with invalid values of
existing options is playing a danergous game in a crucial component like
systemd


It's a rare thing :p but I have to agree with you here!

I'd say if "User=-notauser" then silently failing and using root is
acceptable as per the usual semantics of "- prefix suppresses errors",
but "User=notauser" should fail IMO.


I'm pretty sure you'll find that it does. Specifically, it will fail when 
the child process for the command being executed attempts to map the 
username to a UID.


The issue being discussed here is that systemd considers "0day" to be 
_syntactically_ invalid for a username. See the valid_user_group_name() 
function in basic/user-util.c.


(In my opinion, we shouldn't be this restrictive. POSIX permits usernames 
that start with a digit, and just because certain other utilities can't 
deal with them doesn't mean systemd need forbid them.)


So the directive fails the syntactic check for User=, just like 
Zbigniew's example of User="my name is pretty!".


I do think we ought to have a list of "critical" directives, such that any 
syntactic error in those directives causes the unit load state to be 
"error". For better or worse, people simply don't look at logs, so 
they'll never notice that important directives in their units are being 
ignored.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Github systemd issue 6237

[Reindl Harald]

Am 05.07.2017 um 12:10 schrieb Michael Chapman:

On Wed, 5 Jul 2017, Colin Guthrie wrote:

Reindl Harald wrote on 04/07/17 19:50:

When new configuration options are added, the same unit file can
almost always be used with older systemd, and it'll just warn & ignore
the parts it doesn't understand. Similarly, various configuration
options might be unavailable on some architectures and with some
compilation options. The current behaviour of warn provides
for "soft degradation" in those cases.


frankly a new option on the left side is a completly different thing
than a invalid value - just silently continue with invalid values of
existing options is playing a danergous game in a crucial component like
systemd


It's a rare thing :p but I have to agree with you here!

I'd say if "User=-notauser" then silently failing and using root is
acceptable as per the usual semantics of "- prefix suppresses errors",
but "User=notauser" should fail IMO.


I'm pretty sure you'll find that it does. Specifically, it will fail 
when the child process for the command being executed attempts to map 
the username to a UID.


The issue being discussed here is that systemd considers "0day" to be 
_syntactically_ invalid for a username. See the valid_user_group_name() 
function in basic/user-util.c.


yes and hence it should FAIL the service and not behave silently like 
the left side of a param is unknown on a older version - a invalid VALUE 
in a config has to fail until it's makred with a dash to silent be 
ignored in case of errors


(In my opinion, we shouldn't be this restrictive. POSIX permits 
usernames that start with a digit, and just because certain other 
utilities can't deal with them doesn't mean systemd need forbid them.)


that whole check is by all respect nonsense - if the user *exists* in 
the system you can't pretend it's invalid - if it would be invalid it 
could not have been created to begin with


So the directive fails the syntactic check for User=, just like 
Zbigniew's example of User="my name is pretty!".


I do think we ought to have a list of "critical" directives, such that 
any syntactic error in those directives causes the unit load state to be 
"error". For better or worse, people simply don't look at logs, so 
they'll never notice that important directives in their units are being 
ignored


and that is the problem - at least fall back to "nobody" but for the 
sake of god not to root

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] mkosi.postinst and user home permissions

[Federico Bruni]

Il giorno mar 4 lug 2017 alle 12:28, Federico Bruni 
 ha scritto:

Hi all

I hope this is the right place to ask questions about mkosi.
If not, please advise where I should ask.

I'm building fedora-26 in a directory.
I want to add a normal user, so I've added to mkosi.postinst:

useradd dev -p mypassword
usermod dev -a -G wheel

These two commands work fine, but the permissions are not correct:

# ls -l /home/
total 4
drwxrwxr-x 2 root root 4096 Jul  3 18:13 dev

Is this a bug? Or maybe what I'm trying to do should be accomplished 
in another way?

As a workaround, I might try add a third line to mkosi.postinst:

chown -R dev:dev /home/dev




Further to above, there are more problems:

- files in /etc/skel were not copied in /home/dev
- dev user password is not saved in /etc/passwd, so I cannot log in 
with that user


These problems do not occur if I create an user within the container:

# useradd test -p testing!
# ls -a /home/test/
.  ..  .bash_logout  .bash_profile  .bashrc
# ls -l /home
drwx-- 2 test test 4096 Jul  5 11:45 test

So it's not a bug in shadow-utils.
It must be something about how mkosi.postinst work. Unfortunately I 
don't have any mkosi examples to look at, in order to find any easy 
mistake I might have done.




___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Github systemd issue 6237

[Colin Guthrie]

Reindl Harald wrote on 04/07/17 19:50:
>> When new configuration options are added, the same unit file can
>> almost always be used with older systemd, and it'll just warn & ignore
>> the parts it doesn't understand. Similarly, various configuration
>> options might be unavailable on some architectures and with some
>> compilation options. The current behaviour of warn provides
>> for "soft degradation" in those cases.
> 
> frankly a new option on the left side is a completly different thing
> than a invalid value - just silently continue with invalid values of
> existing options is playing a danergous game in a crucial component like
> systemd

It's a rare thing :p but I have to agree with you here!

I'd say if "User=-notauser" then silently failing and using root is
acceptable as per the usual semantics of "- prefix suppresses errors",
but "User=notauser" should fail IMO.

Col

-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel