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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
In the rootfs these need to run after /var/lib/ has been set up. In the
initrd we want them to run as soon as possible so that they can be used
to customize setting up the rootfs.
Now that we only support serialization into a memfd (rather than a file
in /run/) there's no point to check the free space in /run/. Let's drop it.
One error scenario gone. Yay.
These new calls will do three things:
1. in case of FILE* stuff: flush any pending bytes onto the fd, just in
case
2. seal the backing memfd
3. seek back to the beginning.
Note that this adds sealing to serialization: once we serialized fully,
we'll seal the thing off for further modifications, before we pass the
fd over to the target process. This should add a bit of robustness, and
maybe finds a bug or two one day, if we accidentally write to a
serialization that is complete.
This is just like memfd_new(), but allows fine grained control of the
sealing flags.
This switches over all uses of memfd_new() where we actually want
sealing to use memfd_new_full().
This then allows use to use memfd_new() for two further calls, where we
previously used the more lowlevel memfd_create_wrapper().
Let's use pwrite() to write the contents of the memfd. This has the
benefit of not moving the file offset, which means we don't have to
reset it after at all.
Let's drop support systems lacking memfds, i.e. pre kernel 3.17 systems.
This allows us to drastically simplify the "data fd" concept, so far
that we can remove it entirely.
This replaces acquire_data_fd() with a specialized call to
memfd_new_and_seal(), not that memfds can be the only implementation of
the concept.
We got confused by the error codes here, and sometimes return PAM errors
where the caller propagated them unconverted as negative errno errors. Fix that.
Let's separate four different parts of pam_sm_open_session():
1. Acquiring of our various parameters from pam env, pam data, pam items
2. Mangling of that data to clean it up
3. Registering of the service with logind
4. Importing shell credentials into environment variables
5. Enforcement of user record data
This makes the code a lot more readable, and gets rid of an ugly goto
label.
It also corrects things: if step 3 doesnt work because logind is not
around, we'll now still do step 4, which we previously erroneously
skipped.
Besides that no real code changes.
Let's shorten the code of pam_sm_open_session() a bit, and also make
sure the importing of the env vars from the creds also happens if the
session registration with logind is skipped.
Let's instead just pass over the UserRecord, it's a much more useful
object with lots more information we'll sooner or later need
(preparation for later commits).
We never use the field and this is not going to change...
This addresses a weird asymmetry, as create_session_message() always
went to the process' own PID when doing pidfds but otherwise (i.e.
without pidfds) would honour the PID specified as function parameter.
Let's bump the kernel baseline a bit to 4.3 and thus require ambient
caps.
This allows us to remove support for a variety of special casing, most
importantly the ExecStart=!! hack.
This PR introduces varlink's alternatives to the following DBus methods:
- MapFromMachineUser
- MapToMachineUser
- MapFromMachineGroup
- MapToMachineGroup
Due to a BTRFS issue in kernel 6.12 (and backported in Ubuntu to 6.8)
there's a warning triggered by some tests, and it then causes a panic.
The BTRFS issue has a patch but it is not available in any distro yet,
so disable panic_on_warn until it reaches Arch and Ubuntu Noble. Bugs
have been filed.
