IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
With this "sudo ./run-integration-tests.sh" should work fully without
exception, even on systems lacking SELinux (in which case that test will
just be skipped)
It's always visible:
$ sudo modprobe sit
$ sudo unshare -n ip l
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
...
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
...
grep already indicates if it matched anything by return value.
Additional advantage is then that if the test fails, the unexpected
matching lines are visible in the log output.
No need to go through the specifier_printf() if the path is already too long in
the unexpanded form (since specifiers increase the length of the string in all
practical cases).
In the oss-fuzz test case, valgrind reports:
total heap usage: 179,044 allocs, 179,044 frees, 72,687,755,703 bytes allocated
and the original config file is ~500kb. This isn't really a security issue,
since the config file has to be trusted any way, but just a matter of
preventing accidental resource exhaustion.
https://oss-fuzz.com/v2/issue/4651449704251392/6977
While at it, fix order of arguments in the neighbouring log_syntax() call.
msan doesn't understand sscanf with %ms, so it falsely reports unitialized
memory. Using sscanf with %ms is quite convenient in
socket_address_parse_netlink(), so let's just not run the fuzzer for
ListenNetlink= at all for now. If msan is fixed, we can remove this.
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6884
The orignal reproducer from oss-fuzz depends on the hostname (via %H and %c).
The hostname needs a dash for msan to report this, so a simpler case from
@evverx with the dash hardcoded is also added.
The issue is a false positive from msan, which does not instruct stpncpy
(https://github.com/google/sanitizers/issues/926). Let's add a work-around
until this is fixed.
We have only three bits of space, i.e. 8 possible classes. Immediately reject
anything outside of that range. Add the fuzzer test case and an additional
unit test.
oss-fuzz #6908.
We probably should allow very deep calls of our recursive functions. Let's add
a limit to avoid resource exhaustion. 240 is 10 per hour (if somebody is using
this for time based triggers...), so it should be more than enough for most use
cases, and is conveniently below the 250 stack limit in msan.
oss-fuzz #6917.
Also fix one case where the presence of a newline was used to generate
an invalid environment assignment.
Tested: with mkosi, which builds the local tree and run ninja tests.
gmtime_r() will return NULL in that case, and we would crash.
I committed the reproducer case in fuzz-regressions/, even though we don't have
ubsan hooked up yet. Let's add it anyway in case it is useful in the future. We
actually crash anyway when compiled with asserts, so this can be easily
reproduced without ubsan.
oss-fuzz #6886.
This seems to be a false positive in msan:
https://github.com/google/sanitizers/issues/767.
I don't see anything wrong with the code either, and valgrind does not see the
issue. Anyway, let's add the test case.
We don't have msan hooked up yet, but hopefully we'll in the future.
oss-fuzz #6884.
We currently have just one sanitizer for tests, asan, but we may add more in
the future. So let's keep the loop over the sanitizers in meson.build, but
just enable all regression cases under all sanitizers. If it fails under one
of them, it might fail under a different one.
In subsequent commits I'll add test cases which might not fail under asan,
but it's good to commit them for future use.
The test names are made more verbose:
256/257 fuzz-dns-packet:oss-fuzz-5465:address OK 0.04 s
257/257 fuzz-dns-packet:issue-7888:address OK 0.03 s
The unit files for test-execute are named like
`exec-(setting-name-in-lower-character)-(optional-text).service`.
However, test units for AmbientCapabilities= are not following this.
So, let's rename them for the consistency.
This does not change anything in the functionality of the test.
This PR implements the first part of RFE #8046. I.e. this allows to
write:
```
u username -:300
```
Where the uid is chosen automatically but the gid is fixed.
The nobody user/group may not synthesized by systemd.
To run tests the functionalities in such situation, this adds tests
by user/group by daemon, as it is expected to exists all environments.
A runaway string should still be returned by the code that splits on
commas, so add a '?' to the regex so that the last '"?' in a string
still produces a valid block for the split code.
Tested:
ACTION=="remove\"GOTO=""
Which then produced:
$ test/rule-syntax-check.py src/login/70-uaccess.rules
# looking at src/login/70-uaccess.rules
Invalid line src/login/70-uaccess.rules:10: ACTION=="remove\"GOTO=""
clause: ACTION=="remove\"GOTO=""
Using a regex to match the groups is smarter than the split(',') that
would break in those cases.
Tested:
SUBSYSTEM=="usb", ENV{ID_USB_INTERFACES}=="*:060101:*,*:070202:*", TAG+="uaccess"
Rule checker doesn't break there after this commit.
Add support to backslash-escaped double quote inside a string.
Tested by modifying src/login/70-uaccess.rules to include:
ACTION=="remove" it", GOTO="uaccess_end"
And had the rule checker complain about it:
$ test/rule-syntax-check.py src/login/70-uaccess.rules
# looking at src/login/70-uaccess.rules
Invalid line src/login/70-uaccess.rules:10: ACTION=="remove" it", GOTO="uaccess_end"
clause: ACTION=="remove" it"
This is true since commit 7e760b79ad.
Note that the changes in the regex expressions relies on the fact that the
script assumes that the comma separator is mandatory.
Add a comment in the script to clarify this.
In udev man page, "PROGRAM" key is part of the keys which are used for
matching purposes so it should only be used with the compare operator "==".
Actually it doesn't really make sense to assign it a value.
udev code allows both "=" and "==" for PROGRAM and both are handled the same
way but for consistencies it's better to have only the compare operator allowed
by the rule syntax checker.
No rules shipped by systemd use PROGRAM key so nothing need to be changed in
our rule files.
