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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This makes applying groups after applying the working directory, this
may allow some flexibility but at same it is not a big deal since we
don't execute or do anything between applying working directory and
droping groups.
Rewrite the function to be slightly simpler. In particular, if a specific
match is found (like ConditionVirtualization=yes), simply return an answer
immediately, instead of relying that "yes" will not be matched by any of
the virtualization names below.
No functional change.
Various things don't work when we're running in a user namespace, but it's
pretty hard to reliably detect if that is true.
A function is added which looks at /proc/self/uid_map and returns false
if the default "0 0 UINT32_MAX" is found, and true if it finds anything else.
This misses the case where an 1:1 mapping with the full range was used, but
I don't know how to distinguish this case.
'systemd-detect-virt --private-users' is very similar to
'systemd-detect-virt --chroot', but we check for a user namespace instead.
Fixes:
$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Feb 17 2016 /bin/sh -> dash
$ ./autogen.sh c
./autogen.sh: 22: ./autogen.sh: [[: not found
...
checking whether make supports nested variables... (cached) yes
checking build system type... Invalid configuration `c': machine `c' not
recognized
configure: error: /bin/bash build-aux/config.sub c failed
this is a follow-up for a5e739a570
In case of running test-execute on systems with systemd < v232, several
tests like privatedevices or protectkernelmodules fail because
/run/systemd/inaccessible/ doesn't exist. In these cases, we should skip
tests to avoid unnecessary errors.
See also https://github.com/systemd/systemd/pull/4243#issuecomment-253665566
Since this unit is synthesized anyway there's no point in actually shipping it
on disk. This also has the benefit that "cd /usr/lib/systemd/system ; ls *"
won't be confused by the leading dash of the file name anymore.
Previously, we'd synthesize the root slice unit and the init scope unit in the
enumerator callbacks for the unit type. This is problematic if either of them
is already referenced from a unit that is loaded as result of another unit
type's enumerator logic.
Let's clean this up and simply create the two objects from the enumerator
callbacks, if they are not around yet. Do the actual filling in of the settings
from the unit_load() callbacks, to match how other units are loaded.
Fixes: #4322
This unifies the suggested nsswitch.conf configuration for our four NSS modules to this:
hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname
Note that this restores "myhostname" to the suggested configuration of
nss-resolve for the time being, undoing 4484e1792b.
"myhostname" should probably be dropped eventually, but when we do this we
should do it in full, and not only drop it from the suggested nsswitch.conf
for one of the modules, but also drop it in source and stop referring to it
altogether.
Note that nss-resolve doesn't replace nss-myhostname in full: the former only
works if D-Bus/resolved is available for resolving the local hostname, the
latter works in all cases even if D-Bus or resolved are not in operation, hence
there's some value in keeping the line as it is right now. Note that neither
dns nor myhostname are considered at all with the above configuration unless
the resolve module actually returns UNAVAIL. Thus, even though handling of
local hostname resolving is implemented twice this way it is only executed once
for each lookup.
Let's tighten the cases when our module returns NSS_STATUS_NOTFOUND. Let's do
so only if we actually managed to talk to resolved. In all other cases stick to
NSS_STATUS_UNAVAIL as before, as it clearly indicates that our module or the
system is borked, and the "dns" fallback should really take place.
In particular this fixes the 2nd-level fallback from our own dlopen() based
fallback handling. In this case we really should return UNAVAIL so that the
caller can apply its own fallback still.
Fix-up for d7247512a9.
Note that our own dlopen() based fallback is pretty much redundant now if
nsswitch.conf is configured like this:
hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname
In a future release we should probably drop our internal fallback then, in
favour of this nsswitch.conf-based one.
