Given that we are no longer inspecting the target of the /proc/self/exe
symlink, stop asserting that it has any properties. Remove the plumbing
for wrappersDir, which is no longer used.
Asserting that the binary is located in the specific place is no longer
necessary, because we don't rely on that location being writable only by
privileged entities (we used to rely on that when assuming that
readlink(/proc/self/exe) will continue to point at us and when assuming
that the `.real` file can be trusted).
Assertions about lack of write bits on the file were
IMO meaningless since inception: ignoring the Linux's refusal to honor
S[UG]ID bits on files-writeable-by-others, if someone could have
modified the wrapper in a way that preserved the capability or S?ID
bits, they could just remove this check.
Assertions about effective UID were IMO just harmful: if we were
executed without elevation, the caller would expect the result that
would cause in a wrapperless distro: the targets gets executed without
elevation. Due to lack of elevation, that cannot be used to abuse
privileges that the elevation would give.
This change partially fixes#98863 for S[UG]ID wrappers. The issue for
capability wrappers remains.
/proc/self/exe is a "fake" symlink. When it's opened, it always opens
the actual file that was execve()d in this process, even if the file was
deleted or renamed; if the file is no longer accessible from the current
chroot/mount namespace it will at the very worst fail and never open the
wrong file. Thus, we can make a much simpler argument that we're reading
capabilities off the correct file after this change (and that argument
doesn't rely on things such as protected_hardlinks being enabled, or no
users being able to write to /run/wrappers, or the verification that the
path readlink returns starts with /run/wrappers/).
Before this change it was crucial that nonprivileged users are unable to
create hardlinks to SUID wrappers, lest they be able to provide a
different `.real` file alongside. That was ensured by not providing a
location writable to them in the /run/wrappers tmpfs, (unless
disabled) by the fs.protected_hardlinks=1 sysctl, and by the explicit
own-path check in the wrapper. After this change, ensuring
that property is no longer important, and the check is most likely
redundant.
The simplification of expectations of the wrapper will make it
easier to remove some of the assertions in the wrapper (which currently
cause the wrapper to fail in no_new_privs environments, instead of
executing the target with non-elevated privileges).
Note that wrappers had to be copied (not symlinked) into /run/wrappers
due to the SUID/capability bits, and they couldn't be hard/softlinks of
each other due to those bits potentially differing. Thus, this change
doesn't increase the amount of memory used by /run/wrappers.
This change removes part of the test that is obsoleted by the removal of
`.real` files.
This change includes some stuff (e.g. reading of the `.real` file,
execution of the wrapper's target) that belongs to the apparmor policy
of the wrapper. This necessitates making them distinct for each wrapper.
The main reason for this change is as a preparation for making each
wrapper be a distinct binary.
Wrappers generate pieces of apparmor policies for inclusion, which are
used only in a single place in nixpkgs, for `ping`. They are built only
if apparmor is enabled.
This change causes the test to test:
- that the apparmor includes can be generated,
- that `ping` works with apparmor enabled (as the only policy that
references these includes).
Ideally there would be some other NixOS test that verifies that `ping`
specifically works. Sadly, there isn't one.
password-store.el is on MELPA so it is available in Nixpkgs as
emacs.pkgs.password-store.
Using emacs.pkgs.password-store is preferred because of better package
quality:
- Emacs lisp package dependencies are automatically installed
- byte-compilation is done
- native-compilation is done
There's no "lib" in scope here. The test uses "with pkgs.lib;", so
this failed to evaluate.
Fixes: 6672dde558 ("treewide: use optionalAttrs instead of 'else {}'")
Previously, the transactional template was in id=2.
It is now id=3.
I moved a bit the code to improve the ability to load templates and subscribers properly.
I am planning to upstream `type` for templates API request so we can easily filter out
and select the accordingly template.
dwm is not in Java's internal list of non-reparrenting
window managers. Running Java GUI programs without this
variable on window managers (eg. jd-gui) causes the window
to be blank.
Before this commit there was no way to access (boot into) specialisation of previous generations from grub,even tho they are there.
This commit will add grub submenu for each generation if the generation has any specialisation.
Which will allow you to boot into them.
Co-authored-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
