[systemd-devel] Preferred way to recurse over a directory?
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? Best Albert
Re: [systemd-devel] New developer building systemd
On Fr, 10.09.21 17:44, Marcus Harrison (mar...@harrisonland.co.uk) wrote:
> Hey folks,
>
> I've downloaded the systemd sources and am attempting to build with GCC 9.4 on
> KDE Neon and am receiving the build error described in build-error.txt on
> updated main branch (as of writing).
>
> I've patched around it using the change described in
> remove_unused_function.patch, which allows the build to follow through, but
> the test suite has multiple failures, and requires manual intervention
> multiple times - for example, dropping to a BusyBox recovery shell or log-in
> shell, and some of the tests will hang indefinitely.
>
> I'm wondering how much of this is intended, and if my patch broke
> anything.
You are building without libcryptsetup. Apparently this combination of
build options is currently not tested (i.e. repart on, but
libcryptsetup off).
> diff --git a/src/partition/repart.c b/src/partition/repart.c
> index 926dbb2ae4..8ee78c9b08 100644
> --- a/src/partition/repart.c
> +++ b/src/partition/repart.c
> @@ -206,7 +206,7 @@ static const char *encrypt_mode_table[_ENCRYPT_MODE_MAX]
> = {
> [ENCRYPT_KEY_FILE_TPM2] = "key-file+tpm2",
> };
>
> -DEFINE_PRIVATE_STRING_TABLE_LOOKUP_WITH_BOOLEAN(encrypt_mode, EncryptMode,
> ENCRYPT_KEY_FILE);
> +DEFINE_PRIVATE_STRING_TABLE_LOOKUP_FROM_STRING_WITH_BOOLEAN(encrypt_mode,
> EncryptMode, ENCRYPT_KEY_FILE);
>
Patch looks OK, but instead of replacing the line unconditionally, it
should be one or the other depending on `#if HAVE_LIBCRYPTSETUP`, so
that it then works in both cases.
Would be delighted if you could submit such a patch via github PR.
Lennart
--
Lennart Poettering, Berlin
Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
On Di, 14.09.21 10:26, Mike Gilbert (flop...@gentoo.org) wrote: > > Anyway, I'd be interested in your thoughts about this. i.e. hear > > multiple takes, opinions, from differently people and positions? > > I would definitely like to be able to depend on one crypto/TLS > implementation that would cover all features in systemd, instead of > having to depend on OpenSSL for some features, and GnuTLS for other > features. The current situation is quite messy. > > Settling on OpenSSL sounds fine to me. > > It will probably take a few months for Gentoo to get fully upgraded to > OpenSSL 3.0. Here is our tracker for that: > > https://bugs.gentoo.org/797325 > > Do you have a target date/milestone in mind for introducing this > dependency in systemd? Well, that depends on a) people actually agreeing that this is OK to do, and b) someone actually doing the work. I'd love to do it yesterday. But knowing how things work, this will be a couple of months I guess, maybe half a year. Or could even be longer. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
On Tue, Sep 14, 2021 at 7:36 AM 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? I would definitely like to be able to depend on one crypto/TLS implementation that would cover all features in systemd, instead of having to depend on OpenSSL for some features, and GnuTLS for other features. The current situation is quite messy. Settling on OpenSSL sounds fine to me. It will probably take a few months for Gentoo to get fully upgraded to OpenSSL 3.0. Here is our tracker for that: https://bugs.gentoo.org/797325 Do you have a target date/milestone in mind for introducing this dependency in systemd?
Re: [systemd-devel] Portable services
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: 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. Note that portable services and system extensions are two different things. 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. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Why does sd_path_lookup(SD_PATH_TMPFILES, ..) return one path ?
Hello, I was expecting that this function returns all paths where tmpfiles can be stored but it returns only "/usr/lib/tmpfiles.d". Why doesn't it return also "/etc/tmpfiles.d" ? Thanks you -- Francis
[systemd-devel] Portable services
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). 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). Thanks in advance Umut
Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
On 14/09/2021 13.36, 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 am not an active developer. Nonetheless I would second this, provided the use of OpenSSL does not lead to security vulnerabilities in core non-optional system parts on systems built with the systemd project's outputs. -- Rudd-O https://rudd-o.com/ OpenPGP_signature Description: OpenPGP digital signature
[systemd-devel] [RFC] Switching to OpenSSL 3?
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
Re: [systemd-devel] Filter/Parse NETLINK_KOBJECT_UEVENT Messages
Sorry, I should clarify. The code in sd-device related to BPF I don't understand. What is the 'input' in BPF? Sent from ProtonMail mobile Original Message On 14 Sep. 2021, 5:24 pm, Lennart Poettering wrote: > On Di, 14.09.21 01:08, Ryan McClue (re.mcc...@protonmail.com) wrote: > >> I understand this is slightly off-topic, but I'm completely new to >> BPF. Analyzing libudev source and Internet I understand the general >> idea. However, I don't understand how information/what information >> is passed to the filter from the socket. For example, in my case the >> socket payload, i.e. buf_str = >> add@/devices/pci:00/:00:14.0/usb1/1-2/1-2.4/1-2.4:1.0/input/input38/event14 > >> 1. How do I pass this string to the sock_filter/sock_fprog >> structures? > > You don't. The bpf filtering, and in particular the bloom filter that > is used for that is mostly internal to udev, and not something that is > consider official API and should be reimplemented. > > Use sd-device/libudev, it implements all of this, and is the only official API > to the bpf bloom filter stuff udev does there. > > Lennart > > -- > Lennart Poettering, Berlin
Re: [systemd-devel] Filter/Parse NETLINK_KOBJECT_UEVENT Messages
Earlier you said that .nl_groups = 2 will get kernel uevents augmented by udev. So, at some stage doesn't udev have to parse the raw kernel uevents, i.e. .nl_groups = 1? How does it do this? Does it use BPF to achieve this or the string parsing? -- Ryan McClue, Sydney ‐‐‐ Original Message ‐‐‐ On Tuesday, September 14th, 2021 at 5:24 PM, Lennart Poettering wrote: > On Di, 14.09.21 01:08, Ryan McClue (re.mcc...@protonmail.com) wrote: > > > I understand this is slightly off-topic, but I'm completely new to > > > > BPF. Analyzing libudev source and Internet I understand the general > > > > idea. However, I don't understand how information/what information > > > > is passed to the filter from the socket. For example, in my case the > > > > socket payload, i.e. buf_str = > > > > add@/devices/pci:00/:00:14.0/usb1/1-2/1-2.4/1-2.4:1.0/input/input38/event14 > > > 1. How do I pass this string to the sock_filter/sock_fprog > > > > structures? > > You don't. The bpf filtering, and in particular the bloom filter that > > is used for that is mostly internal to udev, and not something that is > > consider official API and should be reimplemented. > > Use sd-device/libudev, it implements all of this, and is the only official API > > to the bpf bloom filter stuff udev does there. > > Lennart > > - > > Lennart Poettering, Berlin
Re: [systemd-devel] Filter/Parse NETLINK_KOBJECT_UEVENT Messages
On Di, 14.09.21 01:08, Ryan McClue (re.mcc...@protonmail.com) wrote: > I understand this is slightly off-topic, but I'm completely new to > BPF. Analyzing libudev source and Internet I understand the general > idea. However, I don't understand how information/what information > is passed to the filter from the socket. For example, in my case the > socket payload, i.e. buf_str = > add@/devices/pci:00/:00:14.0/usb1/1-2/1-2.4/1-2.4:1.0/input/input38/event14 > 1. How do I pass this string to the sock_filter/sock_fprog > structures? You don't. The bpf filtering, and in particular the bloom filter that is used for that is mostly internal to udev, and not something that is consider official API and should be reimplemented. Use sd-device/libudev, it implements all of this, and is the only official API to the bpf bloom filter stuff udev does there. Lennart -- Lennart Poettering, Berlin
