Re: Bump: Testing LogFilterPatterns= on user-level services

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > 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.




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux