Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.
On Tue, May 30 2017, NeilBrown wrote: > Systemd does not, and will not, support "bg" correctly. > It has other, better, ways to handle "background" mounting. For those who aren't closely watching systemd development, a patch was recently accepted which causes systemd to work correctly with NFS bg mounts. So the above "and will not" was, happily, not correct. So this patch to the nfs documentation is no longer relevant. Thanks everyone, NeilBrown signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Github systemd issue 6237
On Tue, 04 Jul 2017 17:21:01 +, Zbigniew Jędrzejewski-Szmek wrote: > If you need root permissions to create a unit, then it's not a security > issue. An annoyance at most. The fact that you need to be root to create a unit file is irrelevant. Systemd is running a service as a different user to what is defined in the unit file. This is a bug and a local security issue, especially because it will run said service as root. It might not warrant a CVE, although in my line of work this is considered a security issue, but it is a bug and needs fixing. The fix is to refuse to run the service, period. Is there any other place I can go to open a bug, or do I need to go to the upstream "vendor" bugzila? Regards, Abis. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Github systemd issue 6237
Am 04.07.2017 um 20:39 schrieb Zbigniew Jędrzejewski-Szmek: On Tue, Jul 04, 2017 at 07:36:02PM +0200, Reindl Harald wrote: Am 04.07.2017 um 19:21 schrieb Zbigniew Jędrzejewski-Szmek: My question is: Is this a bug with a BZ against rhel/centos7 (as my understanding is that this affects EL7 too)? If there is no BZ and based on the wording of the second to last comment by poettering, will this be fixed/changed in a future update? I personally see this as a security issue and thus as a bug. If you need root permissions to create a unit, then it's not a security issue. An annoyance at most. (You do know that you're not supposed to copy random stuff >from the internet as root, right?) no - when there is a "User=" statement in the unitfile it's a strong reason to refuse start that unit if that user don't exist instead silently fall back to root and casting "0day" to a int 0 is just a sloppy implementation with no good reason It doesn't evaluate "0day" as 0 or cast anything, it (as designed) finds that "0day" is not match the pattern for a valid user name and rejects the whole line. and this is simply *not true* until on each and every system you can't create a user with that name, as long it is not rejected it is valid and systemd is hardly the authoritiy to redefine it Essentially, User=0day is the same as Usre=0day and the same as User="my name is pretty!". which is terrible 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. yes 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 To do this properly, we would need to figure out which options are a) important enough, b) supported on all compilation variants and architectures, and then add a generic mechanism to make errors in them fatal when the value on the right side is invalid you have to fail with a clear error message instead fire up something with undefined behavior, in general but especially when it comes to security relevant things ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Github systemd issue 6237
On Tue, Jul 04, 2017 at 07:36:02PM +0200, Reindl Harald wrote: > > > Am 04.07.2017 um 19:21 schrieb Zbigniew Jędrzejewski-Szmek: > >>My question is: > >> > >>Is this a bug with a BZ against rhel/centos7 (as my understanding is that > >>this affects EL7 too)? > >> > >>If there is no BZ and based on the wording of the second to last comment > >>by poettering, will this be fixed/changed in a future update? > >> > >>I personally see this as a security issue and thus as a bug. > >If you need root permissions to create a unit, then it's not a > >security issue. An annoyance at most. > >(You do know that you're not supposed to copy random stuff > >from the internet as root, right?) > > no - when there is a "User=" statement in the unitfile it's a strong > reason to refuse start that unit if that user don't exist instead > silently fall back to root and casting "0day" to a int 0 is just a > sloppy implementation with no good reason It doesn't evaluate "0day" as 0 or cast anything, it (as designed) finds that "0day" is not match the pattern for a valid user name and rejects the whole line. Essentially, User=0day is the same as Usre=0day and the same as User="my name is pretty!". 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. 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. To do this properly, we would need to figure out which options are a) important enough, b) supported on all compilation variants and architectures, and then add a generic mechanism to make errors in them fatal. 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
Am 04.07.2017 um 19:21 schrieb Zbigniew Jędrzejewski-Szmek: My question is: Is this a bug with a BZ against rhel/centos7 (as my understanding is that this affects EL7 too)? If there is no BZ and based on the wording of the second to last comment by poettering, will this be fixed/changed in a future update? I personally see this as a security issue and thus as a bug. If you need root permissions to create a unit, then it's not a security issue. An annoyance at most. (You do know that you're not supposed to copy random stuff from the internet as root, right?) no - when there is a "User=" statement in the unitfile it's a strong reason to refuse start that unit if that user don't exist instead silently fall back to root and casting "0day" to a int 0 is just a sloppy implementation with no good reason frankly even PHP makes difference here if($bla == "0day") versus if($bla === "0day") the latter won't evaluate to 0 in no case ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Github systemd issue 6237
On Tue, Jul 04, 2017 at 04:59:23PM +, Alexander Bisogiannis wrote: > Hi all, > > https://github.com/systemd/systemd/issues/6237 > > Apologies for asking here, but since the discussion is locked in Github I > thought to ask here. > > This was marked as "not a bug", but in later comments the wording suggests > that systemd behaviour will change No, there's nothing to suggest that in the comments. It *might* change, but the comments do not say that. > and if the username in a unit does not > exist systemd will ignore the unit, instead of running it as root. > > My question is: > > Is this a bug with a BZ against rhel/centos7 (as my understanding is that > this affects EL7 too)? > > If there is no BZ and based on the wording of the second to last comment > by poettering, will this be fixed/changed in a future update? > > I personally see this as a security issue and thus as a bug. If you need root permissions to create a unit, then it's not a security issue. An annoyance at most. (You do know that you're not supposed to copy random stuff from the internet as root, right?) > Again, apologies for asking here, but I cannot comment in the github > discussion due to the thread being locked to maintainers only. Yes, it's locked because of uninformative comments. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Github systemd issue 6237
Hi all, https://github.com/systemd/systemd/issues/6237 Apologies for asking here, but since the discussion is locked in Github I thought to ask here. This was marked as "not a bug", but in later comments the wording suggests that systemd behaviour will change and if the username in a unit does not exist systemd will ignore the unit, instead of running it as root. My question is: Is this a bug with a BZ against rhel/centos7 (as my understanding is that this affects EL7 too)? If there is no BZ and based on the wording of the second to last comment by poettering, will this be fixed/changed in a future update? I personally see this as a security issue and thus as a bug. Again, apologies for asking here, but I cannot comment in the github discussion due to the thread being locked to maintainers only. Regards, Abis. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] mkosi.postinst and user home permissions
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 Thanks in advance Federico ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
