This reverts commit 50cda6433b.
Same as the previous revert, sched.h is too generic to
be included in namespace-util.h, plus this defeats
the purpose of forward decl.
This reverts commit 4d0fe93cba.
I'm not convinced by the reasoning here. The practice of
forward declarations should be confined in headers only,
and any actual invocation of functions in source files
needs to include the original header. strv_split_full()
for instance takes ExtractFlags, and callers will need
to include extract-word.h to get the value definitions.
Now, indeed some -util headers export the most relevant
system header too, notably pidfd-util. But fs-util doesn't
seem to be coupled with any specific header, hence I'm
skeptical about such inclusion.
It will otherwise interpret characters such as '+' as if they
were regex, and break matching.
For example TEST-71-HOSTNAME started failing when
uname -r started including a '+':
FAIL: 'Kernel: Linux 6.12.33+deb13-amd64' not found in:
Static hostname: host
Icon name: computer-vm
Chassis: vm 🖴
Machine ID: e6471c1f95ab49098827498ed816cdf7
Boot ID: 231da987f64d4af59f2076fbb638c611
Virtualization: kvm
Operating System: Debian GNU/Linux 13 (trixie)
Kernel: Linux 6.12.33+deb13-amd64
Architecture: x86-64
Also, if a device ACL list is defined, also go via IPC (instead of
trying to patch it, as before).
The outcome is that the tighter rules continue to apply when configured.
Fixes: #35959
@BUILD_ROOT@ is replaced with the _quoted_ build path. Hence, if
@BUILD_ROOT@ is quoted, the result is doubly quoted, and the script does
not work if the path contains spaces.
Fixes#37953.
access_nofollow() is a simple wrapper of faccessat(), and it is defined as
```
int faccessat(int dirfd, const char *pathname, int mode, int flags);
```
fs-util.h provides access_nofollow() but it did not include neither
fcntl.h nor unistd.h, which define F_OK and friends. Hence we cannot use
the function without including one of the headers. Let's include fcntl.h
in fs-util.h, then we can use the function by simply including fs-util.h.
The additional definitions provided by the header are
- EXT4_IOC_RESIZE_FS, used in resize-fs.c,
- FILEID_KERNFS, used in cgroup-util.c and pidfd-util.c.
Let's drop the inclusion at other places.
Loopback block devices are agressively reused, without being removed in
between. This means various inode attributes on their device nodes will
– so far – remain in effect between uses of the devices. Since there are
applications which change access mode/ownership of such devices after
attaching files to them, let's undo this again when we detect them to be
unused again.
Fixes: #37745
The format is not specific to gpg, it's defined by the pgp
protocols. Lintian even warns about it:
systemd-container: openpgp-file-has-implementation-specific-extension
[usr/lib/systemd/import-pubring.gpg]
Rename it accordingly, as new pgp implementations are slowly becoming
more popular.
Keep using /etc/systemd/import-pubring.gpg for backward compatibility.
The format is not specific to gpg, it's defined by the pgp
protocols. Lintian even warns about it:
systemd-container: openpgp-file-has-implementation-specific-extension [usr/lib/systemd/import-pubring.gpg]
Rename it accordingly, as new pgp implementations are slowly becoming
more popular.
Keep using /etc/systemd/import-pubring.gpg for backward compatibility.
The check was simply wrong and meaningless, as it always checked
CPUSet.allocated is greater than or equals to 1, as sizeof(__cpu_mask) is 8.
Let's make the test more strict.
Some user record providers might want to implement case-insensitive user
record matching, or other forms of non-normalized matching. So far
uderdb didn't allow that, because client's typically revalidate the
returned user records against the search keys (at least our clients do)
– they check if the search user name is actually part of the user record
and its aliases.
In order to support such lookups we thus need to allow the looup keys to
be part of the user record, but also not be persisted in it, because
the number of casings/spellings of a username might be ridiculously
high.
A nice way out is to allow "aliases" not only in the main part of the
record, but also in the "status" part, that contains information
dynamically determined at query time. We can insert a second "aliases"
field there, which the parser will then merge with the primary "aliases"
field, but the existing rules around "status" ensure tha the data is
never persisted.
Follow-up: e2e1f38f5a
So far we already had a logic in place to go for the next mode if some
mode doesn't work – but it was only applied if we'd actively cycle
through resolutions.
Let's extend the logic and always apply it: whenever we try to switch to
a mode, and it doesn't work, go to the next one until we find one that
works.
Fixes: #37324
Let's downgrade the log message about our attempts to deal with an
ordering cycle to warning, because this is a "positive" thing, we try to
improve an earlier error.
OTOH increase the log level when we first log about the cycle to error,
since that highlights the actual problem.
Currently, callers of safe_glob() set an empty glob_t or glob_t with
opendir func, and all other components are always zero.
So, let's introduce safe_glob_full() which optionally takes opendir
function, rather than glob_t, and returns result strv, rather than
storing results in glob_t.
Also, introduce safe_glob() which is a trivial wrapper of
safe_glob_full() without opendir func.
No functional change, just refactoring.
The removed glob() with GLOB_ALTDIRFUNC is exactly the same as what
safe_glob() does, which is tested in TEST(safe_glob) below.
Let's drop the test cases.
Some configuration files that need updates are directly under in /etc. To
update them atomically, we need write access to /etc. For Ubuntu Core this is
an issue as /etc is not writable. Only a selection of subdirectories can be
writable. The general solution is symlinks or bind mounts to writable places.
But for atomic writes in /etc, that does not work. So Ubuntu has had a patch
for that that did not age well.
Instead we would like to introduce some environment variables for alternate
paths.
* SYSTEMD_ETC_HOSTNAME: /etc/hostname
* SYSTEMD_ETC_MACHINE_INFO: /etc/machine-info
* SYSTEMD_ETC_LOCALTIME: /etc/localtime
* SYSTEMD_ETC_LOCALE_CONF: /etc/locale.conf
* SYSTEMD_ETC_VCONSOLE_CONF: /etc/vconsole.conf
* SYSTEMD_ETC_ADJTIME: /etc/adjtime
While it is for now expected that there is a symlink from the standard, we
still try to read them from that alternate path. This is important for
`/etc/localtime`, which is a symlink, so we cannot have an indirect symlink or
bind mount for it.
Since machine-id is typically written only once and not updated. This commit
does not cover it. An initrd can properly create it and bind mount it.
When we load a user record we retain a reference to the original JSON.
Thus the loaded objects might live at least as long as our user record
object, hence we better make sure we set the 'sensitive' flag for the
'secret' section if it's not marked like that yet.
This is paranoia only: we already should be setting this flag properly
earlier, when acquiring the json variant in the first place. But it's
better to be safe than sorry.
We already do this in all placed where we it *really* matters, i.e. for
passwords PINs. But let's do this also at any place where we add the
section at all, regardless whether it is for storing a pw or something
else.
With this we establish the rule that if it's in "secrets", then it
shall be marked "sensitive".
