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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
So far, we considered mount units activated as soon as the mount
appeared. This avoided seeing a difference between mounts started by
systemd, and e.g. by running `mount` from a terminal.
(`umount` was not handled this way).
However in some cases, options passed to `mount` require additional
system calls after the mount is successfully created. E.g. the
`private` mount option, or the `ro` option on bind mounts.
It seems best to wait for mount to finish doing that. E.g. in
the `private` case, the current behaviour could theoretically cause
non-deterministic results, as child mounts inherit the
private/shared propagation setting from their parent.
This also avoids a special case in mount_reload().
It _looks_ as if, back when we used to retry unsuccessful calls to umount,
this would have inflated the effective timeout. Multiplying it by
RETRY_UMOUNT_MAX. Which is set to 32.
I'm surprised if it's true: I would have expected it to be noticed during
the work on NFS timeouts. But I can't see what would have stopped it.
Clarify that I do not expect this to happen anymore. I think each
individual umount call is allowed up to the full timeout, but if umount
ever exited with a signal status, we would stop retrying.
To be extra clear, make sure that we do not retry in the event that umount
perversely returned EXIT_SUCCESS after receiving SIGTERM.
"Due to the io event priority logic we can be sure the new mountinfo is
loaded before we process the SIGCHLD for the mount command."
I think this is a reasonable expectation. But if it works, then the
other comment must be false:
"Note that mount(8) returning and the kernel sending us a mount table
change event might happen out-of-order."
Therefore we can clean up the code for the latter.
If this is working as advertised, then we can make sure that mount units
fail if the mount we thought we were creating did not actually appear,
due to races or trickery (or because /sbin/mount did something unexpected
despite returning EXIT_SUCCESS).
Include a specific warning message for this failure.
If we give up when the mount point is still mounted after 32 successful
calls to /sbin/umount, that seems a fairly similar case. So make that
message a LOG_WARN as well (not LOG_DEBUG). Also, this was recently changed to only
retry while umount is returning EXIT_SUCCESS; in that case in particular
there would be no other messages in the log to suggest what had happened.
It was forbidden to create mount units for a symlink. But the reason is
that the mount unit needs to know the real path that will appear in
/proc/self/mountinfo. The kernel dereferences *all* the symlinks in the
path at mount time (I checked this with `mount -c` running under `strace`).
This will have no effect on most systems. As recommended by docs, most
systems use /etc/fstab, as opposed to native mount unit files.
fstab-generator dereferences symlinks for backwards compatibility.
A relatively minor issue regarding Time Of Check / Time Of Use also exists
here. I can't see how to get rid of it entirely. If we pass an absolute
path to mount, the racing process can replace it with a symlink. If we
chdir() to the mount point and pass ".", the racing process can move the
directory. The latter might potentially be nicer, except that it breaks
WorkingDirectory=.
I'm not saying the race is relevant to security - I just want to consider
how bad the effect is. Currently, it can make the mount unit active (and
hence the job return success), despite there never being a matching entry
in /proc/self/mountinfo. This wart will be removed in the next commit;
i.e. it will make the mount unit fail instead.
The commit b1bfb848046e457f3cd623286b8cc1a5e5440023 makes chase_symlinks()
recognize empty string for root as an invalid parameter. However,
empty root is often used e.g. systemd-nspawn.
This makes chase_symlinks() support empty string safely.
Fixes#7927.
For people who use debug messages, maybe it is helpful to know that
PrivateDevices= failed due to mknod(), and which device node.
(The other (un-logged) failures could be while mounting filesystems e.g. no
CAP_SYS_ADMIN which is the common case, or missing /dev/shm or /dev/pts,
or missing /dev/ptmx).
#7886 caused PrivateDevices= to silently fail-open.
https://github.com/systemd/systemd/pull/7886#issuecomment-358542849
Allow PrivateDevices= to succeed, in creating /dev/ptmx, even though
DeviceControl=closed applies.
No specific justification was given for blocking mknod of /dev/ptmx. Only
that we didn't seem to need it, because we weren't creating it correctly as
a device node.
Add a new -Dllvm-fuzz=true option that can be used to build against
libFuzzer and update the oss-fuzz script to work outside of the
oss-fuzz build environment.
The fuzz targets are intended to be fast and only target systemd
code, so they don't need to call out to any dependencies. They also
shouldn't depend on shared libraries outside of libc, so we disable
every dependency when compiling against oss-fuzz. This also
simplifies the upstream build environment significantly.
The fuzzers will be used by oss-fuzz to automatically and
continuously fuzz systemd.
This commit includes the build tooling necessary to build fuzz
targets, and a fuzzer for the DNS packet parser.
This should have no behavioural effect; it just confused me.
All the other mount directories in this function are created as 0755.
Some of the mounts are allowed to fail - mqueue and hugepages.
If the /dev/mqueue mount target was created with the permissive mode 01777,
to match the filesystem we're trying to mount there, then a mount failure
would allow unprivileged users to write to the /dev filesystem, e.g. to
exhaust the available space. There is no reason to allow this.
(Allowing the user read access (0755) seems a reasonable idea though, e.g. for
quicker troubleshooting.)
We do not allow failure of the /dev/shm mount, so it doesn't matter that
it is created as 01777. But on the same grounds, we have no *reason* to
create it as any specific mode. 0755 is equally fine.
This function will be clearer by using 0755 throughout, to avoid
unintentionally implying some connection between the mode of the mount
target, and the mode of the mounted filesystem.
`newinstance` (and `ptmxmode`) options of devpts are _not_ used by
PrivateDevices=. (/dev/pts is shared, similar to how /dev/shm and
/dev/mqueue are handled). It is used by nspawn containers though.
Also CONFIG_DEVPTS_MULTIPLE_INSTANCES was removed in 4.7-rc2
eedf265aa0
and no longer needs to be set, so make that clearer to avoid confusion.
If /dev/tty did not exist, or had st_rdev == 0, we ignored it. And the
same is true for null, zero, full, random, urandom.
If /dev/ptmx did not exist, we treated this as a failure. If /dev/ptmx had
st_rdev == 0, we ignored it.
This was a very recent change, but there was no reason for ptmx creation
specifically to treat st_rdev == 0 differently from non-existence. This
confuses me when reading it.
Change the creation of /dev/ptmx so that st_rdev == 0 is
treated as failure.
This still leaves /dev/ptmx as a special case with stricter handling.
However it is consistent with the immediately preceding creation of
/dev/pts/, which is treated as essential, and is directly related to ptmx.
I don't know why we check st_rdev. But I'd prefer to have only one
unanswered question here, and not to have a second unanswered question
added on top.
If we take a relative path we first make it absolute, based on the
current working directory. But if CHASE_PREFIX_ROOT is passe we are
supposed to make the path absolute taking the specified root path into
account, but that makes no sense if we talk about the current working
directory as that is relative to the host's root in any case. Hence,
let's refuse this politely.
Some newer BIOS versions of the TrekStor SurfTab wintron 7.0 tablet use
different (better) DMI strings, update the existing 60-sensors.hwdb
entry for this tablet to also work with the newer BIOS.
…otherwise try to clone it as a device node
On most contemporary distros /dev/ptmx is a device node, and
/dev/pts/ptmx has 000 inaccessible permissions. In those cases
the symlink /dev/ptmx -> /dev/pts/ptmx breaks the pseudo tty support.
In that case we better clone the device node.
OTOH, in nspawn containers (and possibly others), /dev/pts/ptmx has
normal permissions, and /dev/ptmx is a symlink. In that case make the
same symlink.
fixes#7878
For old kernels not supporting AmbientCapabilities=, networkd is
started as root with limited capabilities. Then, networkd cannot
chown the directories under runtime directory as
CapabilityBoundingSet= does not contains enough capabilities.
This makes these directories are created after dropping privileges.
Thus, networkd does not need to chown them anymore.
Fixes#7863.
This fixes the following warnings:
```
[194/1521] Compiling C object 'src/libsystemd-network/systemd-network@sta/dhcp6-option.c.o'.
../../git/systemd/src/libsystemd-network/dhcp6-option.c:110:25: warning: taking address of packed member 'id' of class or structure 'ia_na' may result in an unaligned pointer value [-Waddress-of-packed-member]
iaid = &ia->ia_na.id;
^~~~~~~~~~~~
../../git/systemd/src/libsystemd-network/dhcp6-option.c:115:25: warning: taking address of packed member 'id' of class or structure 'ia_ta' may result in an unaligned pointer value [-Waddress-of-packed-member]
iaid = &ia->ia_ta.id;
^~~~~~~~~~~~
2 warnings generated.
```
