Drop globbing of rules/*.rules in the rules-test.sh wrapper and move that logic
into the actual test rule-syntax-check.py. This can still be called with
individual rules files, but when being called without arguments it will now
process all top_builddir/rules/*.rules.
Preparation for dropping the shell wrappers altogether.
When we set up a loopback device with partition probing, the udev
"change" event about the configured device is first passed on to
userspace, only the the in-kernel partition prober is started. Since
partition probing fails with EBUSY when somebody has the device open,
the probing frequently fails since udev starts probing/opening the
device as soon as it gets the notification about it, and it might do so
earlier than the kernel probing.
This patch adds a (hopefully temporary) work-around for this, that
compares the number of probed partitions of the kernel with those of
blkid and synchronously asks for reprobing until the numebrs are in
sync.
This really deserves a proper kernel fix.
Plain implies a ... "plain" output.
Also do not say "No jobs" with --no-legend. We skip
reporting the number of jobs with --no-legend if there
are any, and 0 is also a number, and should be skipped.
There is no reason to provide our own attach_flags_mask. We can simply
rely on kdbus.attach_flags_mask= which is read by the kernel *and* kmod.
If it's set, we assume the user wants to override our setting, so we
simply skip setting it.
The kernel module system is not namespaced, so no container should ever
modify global options. Make sure we set the kdbus attach_flags_mask only
on a real boot as PID1.
If the received NTP message from server didn't fit to our buffer, either
it is doing something nasty or we don't know the protocol. Consider the
packet as invalid.
(David: add parantheses around conditional)
While it's a lovely scenario, it's probably not really useful. Fix our
GetConnectionUnixUser() to return the actual 'euid' which we asked for,
not the possible uninitialized 'uid'.
This reverts commit 68e68ca810. We *need*
root access to create cgroups. The only exception is if it is run from
within a cgroup with "Delegate=yes". However, this is not always true and
we really shouldn't rely on this.
If your terminal runs from within a systemd --user instance, you're fine.
Everyone else is not (like running from ssh, VTs, and so on..).
If we set SD_BUS_CREDS_AUGMENT, we *need* the PID from the kernel so we
can lookup further information from /proc. However, we *must* set
SD_BUS_CREDS_PIDS in "mask", otherwise, our creds-collector will never
actually copy the pid into "sd_bus_creds". Fix this, so
SD_BUS_CREDS_AUGMENT works even if SD_BUS_CREDS_PID is not specified by
the caller.
Whenever a process performs an action on an object, the kernel uses the
EUID of the process to do permission checks and to apply on any newly
created objects. The UID of a process is only used if someone *ELSE* acts
on the process. That is, the UID of a process defines who owns the
process, the EUID defines what privileges are used by this process when
performing an action.
Process limits, on the other hand, are always applied to the real UID, not
the effective UID. This is, because a process has a user object linked,
which always corresponds to its UID. A process never has a user object
linked for its EUID. Thus, accounting (and limits) is always done on the
real UID.
This commit fixes all sd-bus users to use the EUID when performing
privilege checks and alike. Furthermore, it fixes unix-creds to be parsed
as EUID, not UID (as the kernel always takes the EUID on UDS). Anyone
using UID (eg., to do user-accounting) has to fall back to the EUID as UDS
does not transmit the UID.
Make sure we tell the kernel to fake all UIDs/GIDs. Otherwise, the remote
side has no chance of querying our effective UID (which is usually what
they're interested in).
