Re: [systemd-devel] Bump: Testing LogFilterPatterns= on user-level services
Hi, and thanks to all of you for the information and discussion! I just opened issue https://github.com/systemd/systemd/issues/31113 for this using vanilla labels and component. Pls change as required. Thanks.
Re: [systemd-devel] Bump: Testing LogFilterPatterns= on user-level services
> > Interepreting arbitrary regexes configured by unpriv code in priv code > > comes at some risk,. becose afair constructing them can come at O(2^n) > > time, i.e. a rogue regex could make use consume unbounded time on > > processing journal messages. > > Which regex engine is used? glibc’s engine is not safe for use with > untrusted input, but Rust’s is, so that might be an option in the > future. It isn’t OOM-safe, though. Rust isn't used. To my knowledge libpcre2 is used (at least it was at the time the feature landed). That library does not seem to allow setting any restrictions which would make it possible to parse untrusted input. For how exactly this works for rust see the documentation of the crate: https://docs.rs/regex/latest/regex/index.html#untrusted-input So in theory it is certainly possible to allow a regex subset though I am not aware of any C library which does this. A simple workaround we have done in a project I work on is to restrict the set of allowed characters. Doing it that way however puts more restrictions in place than theoretically possible. For the foreseeable future I agree with Lennart that documenting this quirk should be the most important thing. Afterwards this could be made configurable somehow, as well as showing a message or exiting with a non-zero code to indicate that this is not allowed.
Re: [systemd-devel] Bump: Testing LogFilterPatterns= on user-level services
On Fri, Jan 26, 2024 at 09:11:24AM +0100, Lennart Poettering wrote: > On Do, 25.01.24 22:29, Farblos (akfkqu.9df...@vodafonemail.de) wrote: > > > Hi. > > > > I sent below mail some week ago, Barry's reply left me unsure as to > > whether this would be a bug or not. I still tend do assume that I'm > > "doing something wrong". > > This is currently not supported. The filters are communicated by the > service manager to journald via xattrs on the cgroups, and journald > will only consider those for cgroups owned by root, i.e. not on > cgroups delegated to unpriv users like this done for systemd --user > instances. > > Interepreting arbitrary regexes configured by unpriv code in priv code > comes at some risk,. becose afair constructing them can come at O(2^n) > time, i.e. a rogue regex could make use consume unbounded time on > processing journal messages. Which regex engine is used? glibc’s engine is not safe for use with untrusted input, but Rust’s is, so that might be an option in the future. It isn’t OOM-safe, though. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
Re: [systemd-devel] Bump: Testing LogFilterPatterns= on user-level services
> Interepreting arbitrary regexes configured by unpriv code in priv code > comes at some risk,. becose afair constructing them can come at O(2^n) > time, i.e. a rogue regex could make use consume unbounded time on > processing journal messages. > > Hence, I wouldn't hold your breath. Unless someone figures out a smart > way to deal with this it's unlikely to be supported. I am not sure about construction but checking for matches with arbitrary regexes can definitely result in DOS. Restricting the allowed features, however, alleviates this problem. E.g. the rust regex crate can check in O(m*n) with m = Regex Size and n = Input size. It does this by now allowing (amongst other things) no look-arounds or backrefs. I am not sure how configurable pcre2pattern is but maybe the supported features could be restricted for regexes from users. Nils
Re: [systemd-devel] Bump: Testing LogFilterPatterns= on user-level services
On Do, 25.01.24 22:29, Farblos (akfkqu.9df...@vodafonemail.de) wrote: > Hi. > > I sent below mail some week ago, Barry's reply left me unsure as to > whether this would be a bug or not. I still tend do assume that I'm > "doing something wrong". This is currently not supported. The filters are communicated by the service manager to journald via xattrs on the cgroups, and journald will only consider those for cgroups owned by root, i.e. not on cgroups delegated to unpriv users like this done for systemd --user instances. Interepreting arbitrary regexes configured by unpriv code in priv code comes at some risk,. becose afair constructing them can come at O(2^n) time, i.e. a rogue regex could make use consume unbounded time on processing journal messages. Hence, I wouldn't hold your breath. Unless someone figures out a smart way to deal with this it's unlikely to be supported. We should document this however I guess. Hence if you file an issue that would be more than welcome, so that we can keep trakc of this. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Bump: Testing LogFilterPatterns= on user-level services
Hi. I sent below mail some week ago, Barry's reply left me unsure as to whether this would be a bug or not. I still tend do assume that I'm "doing something wrong". So before I open an issue on GitHub, I'll give it another try here. Thanks. I'm playing with the LogFilterPatterns= directive on user-level services, not very successfully so far. [~]$ systemd --version systemd 255 (255.2-3) +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified Here is my testcase for a user-level service illustrating my problem: Create a file /tmp/test.sh with the following contents: - test.sh - while :; do echo ritzelbimpf echo ritzelbimpf | logger echo ritzelbimpf | systemd-cat echo foobarbaz echo foobarbaz | logger echo foobarbaz | systemd-cat sleep 10 done - test.sh - Create a user-level service in file ~/.config/systemd/user/test.service with the following contents: - test.service - [Unit] Description=test service [Service] ExecStart=/bin/bash /tmp/test.sh LogFilterPatterns=~ritzelbimpf - test.service - Then execute: [~]$ systemctl --user daemon-reload [~]$ systemctl --user start test.service [~]$ systemctl --user stop test.service This results in the following messages in the journal for me: - test.service - Jan 12 14:36:30 host01 systemd[1377]: Reloading... Jan 12 14:36:30 host01 systemd[1377]: Reloading finished in 69 ms. Jan 12 14:36:37 host01 systemd[1377]: Started test.service - test service. Jan 12 14:36:37 host01 bash[3372]: ritzelbimpf Jan 12 14:36:38 host01 farblos[3374]: ritzelbimpf Jan 12 14:36:38 host01 cat[3376]: ritzelbimpf Jan 12 14:36:38 host01 bash[3372]: foobarbaz Jan 12 14:36:38 host01 farblos[3379]: foobarbaz Jan 12 14:36:38 host01 cat[3381]: foobarbaz Jan 12 14:36:45 host01 systemd[1377]: Stopping test.service - test service... Jan 12 14:36:45 host01 systemd[1377]: Stopped test.service - test service. - test.service - That is, these "ritzelbimpf" messages come through unfiltered. What am I missing here? And: If my approach is fundamentally flawed, how would a minimal test case for a user-level service look like that demonstrates how/that LogFilterPatterns= works?
