tty_is_vc() is more often than not used for simple "categorization"
than validity check. E.g. in logind, we first recognize the tty
"looks like vc", and then use vtnr_from_tty() where range check
is performed and vtnr is extracted. In such cases, we want to reject
invalid vtnr from clients rather than silently carry on, hence
let's remove bound check in tty_is_vc().
Fixes#36166
Replaces #36167 and #36175
Now that nspawn can run unprivileged off directory trees owned by
the new "foreign" UID range let's make sure homed actually allows
files owned by that range in the home directories.
This is not enough to make nspawn just work in homed home dirs
unfortunately though. that's because homed applies an idmapping, and
nspawn would need to then to take that idmapped mount and apply another
one, and the kernel simply doesn't support stacked idmapped mounts.
There's work ongoing to address that in the kernel.
However, this is a first step, and should be enough to make things just
work should the kernel eventually support stacked idmapped mounts.
An object json is a set of key and value pair, hence has its number of
element is multiple of two, and we know at least two elements there.
Follow-up for b6a2df6307.
Fixes CID#1590724
Then, we can avoid that files outside of sysfs are written by udev ATTR key.
This also makes
- logs failure in udev_resolve_subsys_kernel(),
- failure in sd_device_get_syspath() critical, as that should not happen,
- cache the value to be write when running on test mode, to make it
shown by OPTIONS="dump" or obtained by ATTR match token.
This adds the same sections we already have in the homectl --help blurb
also to the man page.
While we are at it, let's also add a new section for Authentication
related switches.
There's finally quota on tmpfs, hence let's use it to make it harder for
users to DoS the system by consuming all disk space in /tmp/ and
/dev/shm/.
This enforces a default limit of 80% quota of the backing fs for these
two dirs for users, but this can be overriden in the user record, if
desired.
This also adds two other interesting features:
1. mount units gain GracefulOptions= which takes optional mount options
that are added only if supported by the kernel. (this is used to enable
usrquota on /tmp/, if available.)
2. The PAM logic in service management now supports reading passwords
from service credentials and via the askpw logic. This used for make
testing easy (so that we can run0 into a homed user which strictly
requires a password).
So far nspawn supported unpriv containers only if backed by a DDI. This
adds dir-based unpriv containers too.
To make this work this introduces a new UID concept to systemd: the
"foreign UID range". This is a high UID range of size 64K. The idea is
that disk images that are "foreign" to the local system can use that,
and when a container or similar is invoked from it, a transiently
allocated dynamic UID range is mapped from that foreign UID range via id
mapped mounts.
This means the fully dynamic, transient UID ranges never hit the disk,
which should vastly simplify management, and does not require that uid
"subranges" are persistently delegated to any users.
The mountfsd daemon gained a new method call for acquiring an idmapped
mount fd for an mount tree owned by the foreign UID range. Access is
permitted to unpriv clients – as long as the referenced inode is located
within a dir owned by client's own uid range.
Enforce the quota on these two tmpfs at the same place where we mount
the per-user $XDG_RUNTIME_DIR. Conceptually these are very similar
concepts, and it makes sure to enforce the limits at the same place with
the same lifecycle.
Sometimes it's nice being able to store dev_t as pointer values in
hashmaps/tables, instead of having to allocate memory for them and using
devt_hash_ops. After all dev_t is weird on Linux/glibc: glibc defines it
as 64bit entity (which hence appears as something we cannot encode in a
pointer value for compat with 32bit archs) but it actually is 32bit in
the kernel apis. Hence we can safely cut off the upper 32bit, and still
retain compat with all archs.
But let's hide this in new macros, and validate this is all correct via
a test.
So far, we supported two modes:
1. when running unpriv we'd get the mounts from mountfsd, and the userns
from nsresourced
2. when running priv we'd do the mounts/userns ourselves
This untangles this a bit, so that we can also use mountfsd/nsresourced
when running privilged.
I think this is generally a bit nicer, and probably something we should
switch to entirely one day, as it reduces the variety of codepaths.
With this patch the default behaviour remains unchanged, but by
selecting the new "managed" option for --private-users= the codepaths
via mountfsd/nsresourced can be explicitly requested even when running
with privs.
This is mostly just reworks that we check for arg_userns_mode !=
USER_NAMESPACE_MANAGED rather than arg_privileged for a number of
codepaths, but requires more fixes, too. The devil is in the details.
This adds a new "foreign" value to --private-users-ownership= which is a
lot like "map", but maps from the host's foreign UID range rather than from the
host's 0.
(This has nothing much to do with making unprivileged directory-based
containers work, it's just very handy that we can run privileged
contains with such a mapping too, with an easy switch)
This simply calls into mountfsd to acquire the root mount and uses it as
root for the container.
Note that this also makes one more change: previously we ran containers
directory off their backing directory. Except when we didn't, and there
were a variety of exceptions: if we had no privs, if we ran off a disk
image, if the directory was the host's root dir, and some others.
This simplifies the logic a bit: we now simply always create a temporary
directory in /tmp/ and bind mount everything there, in all code paths.
This simplifies our code a bit. After all, in order to control
propagation we need to turn the root into a mount point anyway, hence we
might just do it at one place for all cases.
systemd-mountfsd so far provided a MountImage() API call for mounting a
disk image and returning a set of mount fds. This complements the API
with a new MountDirectory() API call, that operates on a directory
instead of an image file. Now, what makes this interesting is that it
applies an idmapping from the foreign UID range to the provided target
userns – and in which case unpriveleged operation is allowed (well,
under some conditions: in particular the client must own a parent dir of
the provided path).
This allows container managers to run fully unprivileged from
directories – as long as those directories are owned by the foreign UID
range. Basic operation is like this:
1. acquire a transient userns from systemd-nsresourced with 64K users
2. ask systemd-mountfsd for an idmapped mount of the container dir
matching that userns
3. join the userns and bind the mount fd as root.
Note that we have to drop various sandboxing knobs from the mountfsd
service file for this to work, since the kernel's security checks that
try to ensure than an obstructed /proc/ cannot be circumvented via
mounting a new procfs will otherwise prohibit mountfsd to duplicate the
mounts properly.
We currently set this at two distinct places right before calling
userdb_connect(). let's do this inside of userdb_connect() instead, and
derive it directly from the socket path.
This doesn't change behaviour but simplifies things a bit.
The GetUserRecord() and GetMemberships() have quite different arguments,
hence let's use separate structures for both.
This makes sense on its own, since it makes the structures a bit
smaller, but is also preparation for a later commit that adds a bunch of
new fields to one of the structs but not the other.