Re: [systemd-devel] Examples to distinguish Before=/After= and Wants=/Requires=/BindsTo=
Am Mi, 15. Sep 2021, um 19:23, schrieb Andrei Borzenkov: > On 15.09.2021 18:15, Manuel Wagesreither wrote: > > Hello all, > > > > I'm onboarding some collegues who don't have much experience with systemd. > > One thing I would like to focus on is the difference between Before=/After= > > and Wants=/Requires=/BindsTo in systemd units. > > > > I think it would get immediately clear if could provide them an example > > where we want one but not the other. Unfortunately I've got problems coming > > up with such an example. In my use cases, whenever I needed an After= I > > needed an Wants= as well. > > > > Can you come up with something good? > > > > No. B After A means - select start job for B for execution after start > job for A completes. This directive is only meaningful if you guarantee > that both start jobs are present in the queue. And the only way to > ensure it is to use Wants (or Requires as variant). > > If service B really needs service A to be started before it itself can > be started, you must use After and Wants, otherwise you are open to race > conditions. And if service B does not care if service A is started, then > you do not need After in the first place. > > Of course one can try to ensure that all start jobs are present in queue > by some external means. Like making all units to be WantedBy some > super-unit which is called ... default.target (surprise). But that does > not change underlying requirement, just restricts working case to > starting one single unit. Presumably on system boot :) > I understand. Still, I'm looking for giving the people I teach an example why it made sense to implement it this way. Something else than just saying "that's just how it is, just accept it".
Re: [systemd-devel] Examples to distinguish Before=/After= and Wants=/Requires=/BindsTo=
On 15.09.2021 18:15, Manuel Wagesreither wrote: > Hello all, > > I'm onboarding some collegues who don't have much experience with systemd. > One thing I would like to focus on is the difference between Before=/After= > and Wants=/Requires=/BindsTo in systemd units. > > I think it would get immediately clear if could provide them an example where > we want one but not the other. Unfortunately I've got problems coming up with > such an example. In my use cases, whenever I needed an After= I needed an > Wants= as well. > > Can you come up with something good? > No. B After A means - select start job for B for execution after start job for A completes. This directive is only meaningful if you guarantee that both start jobs are present in the queue. And the only way to ensure it is to use Wants (or Requires as variant). If service B really needs service A to be started before it itself can be started, you must use After and Wants, otherwise you are open to race conditions. And if service B does not care if service A is started, then you do not need After in the first place. Of course one can try to ensure that all start jobs are present in queue by some external means. Like making all units to be WantedBy some super-unit which is called ... default.target (surprise). But that does not change underlying requirement, just restricts working case to starting one single unit. Presumably on system boot :)
[systemd-devel] Examples to distinguish Before=/After= and Wants=/Requires=/BindsTo=
Hello all, I'm onboarding some collegues who don't have much experience with systemd. One thing I would like to focus on is the difference between Before=/After= and Wants=/Requires=/BindsTo in systemd units. I think it would get immediately clear if could provide them an example where we want one but not the other. Unfortunately I've got problems coming up with such an example. In my use cases, whenever I needed an After= I needed an Wants= as well. Can you come up with something good? Thanks, regards, Manuel
Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
On Tue, 2021-09-14 at 13:36 +0200, Lennart Poettering wrote: > Heya! > > Some of the systemd developers have been discussing switching > systemd's crypto libraries to be exclusively OpenSSL 3.0, and drop > support for older OpenSSL versions, as well as any GNUTLS/libgcrypt > support. As you might have noticed OpenSSL 3.0 has been released > recently, and for the first time resolves the GPL2 license > incompatibility mess comprehensively, which opens this door to us. > > I personally care a lot about reducing the combinatorial explosion of > deps a bit, and keeping our tree as maintainable as we can, with a > single implementation of everything, not multiple, and no abstraction > layers and such, and thus removing any compat kludges for other > libraries or other library versions. > > Now, before we make a decision on this, I'd like to collect feedback > on such a move. I know that there are some people who backpart new > systemd onto old distros. How big would the pain be require porting > OpenSSL 3, too, at the same time? > > (What's not up for discussion: for new additions to systemd we'll do > only OpenSSL, and won't accept anything else. My question is really > just about the stuff we aleady have, where we currently support > GNUTLS/libcgrypt.). > > Anyway, I'd be interested in your thoughts about this. i.e. hear > multiple takes, opinions, from differently people and positions? > > Thanks, > > Lennart To summarize in public what we discussed elsewhere: - OpenSSL 3 is licensed under Apache2 which is compatible with GPLv3 but believed by many to be incompatible with GPLv2 - systemd is mostly (L)GPLv2+, with no specific OpenSSL exception clauses - distributors of the built and linked binaries can safely and without any reasonable doubt get over the perceived incompatibility by declaring that the GPLv2+ binaries linked to OpenSSL are distributed under GPLv3 The issue of course is with the "mostly" keyword. There are many compat-headers backported from Linux UAPI headers, but they are covered by the Linux syscall-note exception so they explicitly do not affect the license of the binaries built with them. There are however three GPLv2-only headers with no exceptions currently included in all builds: - src/basic/ioprio.h which is in the process of being removed via https://github.com/systemd/systemd/pull/20736 - src/basic/linux/loadavg.h which is copied from https://github.com/torvalds/linux/blob/master/include/linux/sched/loadavg.h - src/shared/linux/bpf_insn.h which is copied from https://github.com/torvalds/linux/blob/master/samples/bpf/bpf_insn.h The third one to me seems the most problematic one, as it's fairly complex and thus is unlikely to be perceived universally as exempt from copyright. It is very annoying as it is clearly a "sample" source file, which usually is intended to be reused liberally, and originally it was without a license and was given GPLv2-only when the big SPDX refactor happened. There are 5 companies or so holding copyright on that file, so perhaps a quick avenue would be to seek their permission to dual license it? BPF support in systemd is of course optional, so it could instead be disabled everywhere so that the header is excluded at build time, but it would be quite unfortunate. This covers the situation regarding executables (and internal details). The point was raised that we also have a public shared library, libsystemd.so, which is currently licensed as LGPLv2+. This links to libgcrypt.so, which is slated for replacement by OpenSSL. But doing so would mean that the shared library would then have to be distributed under LGPLv3+, which would be a massive headache for many many reasons that I am not going to get into here, as programs link to it directly. libgcrypt is used by two source files in libsystemd: src/libsystemd/sd-journal/fsprg.c src/libsystemd/sd-journal/journal-authenticate.c The first uses it to calculate HMACs, the second to get high quality random numbers. There would seem to be 3 solutions to keep libsystemd.so distributed under LGPLv2: 1) Keep using libgcrypt only in those two files and remove it everywhere else 2) Find a third GPLv2-compatible solution in place of libgcrypt for those two files 3) Deprecate and remove those APIs We generally do not break backward compatibility in the public library for good reasons so the third one is out, and in the short term the second one is going to be quite difficult. So perhaps the best way forward is at least for the initial switch to keep libgcrypt in place exclusively for libsystemd.so, and then eventually remove it without adding libcrypto in its place? It has been pointed out that some HMAC primitives might be available under: https://github.com/dot-asm/cryptogams -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
On Tue, 2021-09-14 at 13:36 +0200, Lennart Poettering wrote: > Heya! > > Some of the systemd developers have been discussing switching > systemd's crypto libraries to be exclusively OpenSSL 3.0, and drop > support for older OpenSSL versions, as well as any GNUTLS/libgcrypt > support. As you might have noticed OpenSSL 3.0 has been released > recently, and for the first time resolves the GPL2 license > incompatibility mess comprehensively, which opens this door to us. > > I personally care a lot about reducing the combinatorial explosion of > deps a bit, and keeping our tree as maintainable as we can, with a > single implementation of everything, not multiple, and no abstraction > layers and such, and thus removing any compat kludges for other > libraries or other library versions. > > Now, before we make a decision on this, I'd like to collect feedback > on such a move. I know that there are some people who backpart new > systemd onto old distros. How big would the pain be require porting > OpenSSL 3, too, at the same time? This will be an issue for CentOS Stream 8, among others. We ship a backport of the latest systemd (and dailies from the github master) for it as part of the CentOS Hyperscale SIG (https://wiki.centos.org/SpecialInterestGroup/Hyperscale). C8 currently ships OpenSSL 1.1.1k, and given that this is a package from base it's unlikely to get bumped throughout the lifecycle of the distro. We could theoretically build OpenSSL 3 as part of Hyperscale, but that would require rebuilding half the distribution, which is obviously not practical. We might be able to build and ship a coinstallable private OpenSSL 3 build just for systemd, but I don't know how technically feasible that'll be in practice, and it'll definitely be a pain to maintain and likely bring along some security fun. The same issue applies to CentOS 7, though we've stopped building backports for that past 246 so we're not directly impacted there. Now, that good news is that this won't be an issue at all for CentOS Stream 9, as they've just rebased to 3.0.0 last week (https://gitlab.com/redhat/centos-stream/rpms/openssl). Cheers Davide
Re: [systemd-devel] Preferred way to recurse over a directory?
On Wed, 2021-09-15 at 10:43 +0200, Lennart Poettering wrote: > On Di, 14.09.21 23:26, Albert Brox (alb...@exypno.tech) wrote: > > > I'm working on PR #20239 loadcred-dir and wondering what the preferred way > > to recurse over a directory is. > > > > I was told recursively calling the `load_credential` function is too racy so > > I'm led to ftw/nftw. However I see in the TODO file, "Get rid of nftw(). We > > should refuse to use such useless APIs on principle." Can anyone point me in > > the right direction? > > Do your own recursion, use xopendirat() to get a subdir fd from a dir > fd, and then call your funciton on that, always iterating with > readdir() as needed. > > (Probably best to keep these discussions on the PR though). > > Lennart I have had this implementation in my downstream tree for a while (no use for it upstream yet), feel free to cherry-pick and use it for your PR: https://github.com/bluca/systemd/commit/58a36591a4b4353232d024f26d253995bd88f99d -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] Preferred way to recurse over a directory?
On Di, 14.09.21 23:26, Albert Brox (alb...@exypno.tech) wrote: > I'm working on PR #20239 loadcred-dir and wondering what the preferred way > to recurse over a directory is. > > I was told recursively calling the `load_credential` function is too racy so > I'm led to ftw/nftw. However I see in the TODO file, "Get rid of nftw(). We > should refuse to use such useless APIs on principle." Can anyone point me in > the right direction? Do your own recursion, use xopendirat() to get a subdir fd from a dir fd, and then call your funciton on that, always iterating with readdir() as needed. (Probably best to keep these discussions on the PR though). Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Portable services
On 2021-09-14, 3:43 PM, "Lennart Poettering" wrote: On Di, 14.09.21 12:10, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote: > Hello, > > We, at Axis, have a monolithic operating system backed by a > platform. There are teams behind the services making up the > operating system and we have quite many services. We have been > investigating sandboxing these services and of course systemd > sandboxing directives are a way to go. Problem is that it is not > realistic for us to expect teams to be on top of the directives and > apply the right ones they need (and keep them updated). There shines > the portable services for us with it’s “profiles”. We are trying to > sandbox these services while giving them some host access. There > shined for example how the default profile is set up by giving dbus > access (binding dbus system socket to a portable service). We would > like to create a base runtime and expect services to use the base > runtime, still giving them the option of overriding the > runtime. There shined the stackable services with latest “extension” > support. All and all it fits our use case very well. > > I am aware that portable services is still enhancing but who out > there is using it and I am curious about their use case. (Sorry, > couldn’t wait for spring in Berlin). The commit history to that dir might give you hint which companies use it: Thanks for the suggestion. https://github.com/systemd/systemd/commits/main/src/portable But of course, that's only the ones which use it *and* contribute to it. I am pretty sure there are others which use it, but don't contribute. > Seems like DynamicUsers is part of the default profile and > DynamicUsers is a good thing. Seems like systemd creates a username > as the same name as the portable service. Does it work with username > based dbus policies? Is it that we need to be very careful regarding > who can start a portable service in case they re-use service name to > go around dbus rules (vs who can edit /etc/passwd). So, providing D-Bus services from DynamicUser= services is messy. The two D-Bus brokers out there want to resolve user names at the time they load policy, and that of course conflicts with the DynamicUser= concept to some level, since loading policy happens at early boot but the whole point of DynamicUser= is that these users only appear the moment the service starts. The opposite, i.e. connecting as a client to D-Bus services from DynamicUser= should be OK (it just means you need to be able to connect to the D-Bus system socket from the service, i.e. you need to bind mount that socket) — as long as your client is just a regular client, i.e. doesn't need specific broker-side policy. Thankfully clients that require installation of specific D-Bus policies is the exception. D-Bus progress is currently a bit stuck. Ideally D-Bus maintainers would provide us with a way how we could marry socket activation and D-Bus a bit (in the sense, that systemd passes a pre-connected D-Bus socket to services, for example, and also uploads policy at that moment). But I wouldn't hold my breath this happens anytime soon. Sounds like a good idea. Note that portable services and system extensions are two different things. Sorry for misusing the term. I have meant "portablectl --extension" option. Regarding system extensions: at RH we are working on using them as a way to build fully trusted initrds at the moment. background: it's currently a major shortcoming of generic Linux distros that initrds are entirely unprotected cryptographically, anyone can modify them at will without this being detectable, making FDE pretty weak conceptually; SecureBoot only covers the kernel, but once the initrd is run all safety is off. I recently pushed a PR that adds embedded offline-safe PKCS#7 signature support to the disk image logic that system extensions and portable services build on (and nspawn, …). With that you get really nice security properties, as we reinvent initrds in secure, trusted way: the basic initrd is now built into the kernel (and thus validated along with it), and exotic storage is then added in via trusted, verifiable system extensions. Interesting to hear. Thanks for your feedback and looking forward to hear from others. Umut Lennart -- Lennart Poettering, Berlin
