Re: [systemd-devel] user slice changes for uid ranges

[Jérémy ROSEN]

I don't have a complete solutions, but here are a couple of tools that you
might be able to assemble into something that work
* dropins,  you could do a dropin for every existing UID that sets the
Slice= field
* generators : could be used to generate those dropins
* also note that if a unit is named a-b-c.service, systemd will look for
dropins named a-b-.service and a-.service... there might be something to do
with that, but I havn't given it much thought

Le ven. 27 sept. 2019 à 18:28, Mantas Mikulėnas  a
écrit :

> On Fri, Sep 27, 2019 at 5:03 PM Stijn De Weirdt 
> wrote:
>
>> hi all,
>>
>> i'm looking for an "easy" way to set resource limits on a group of users.
>>
>> we are lucky enough that this group of users is within a (although
>> large) high enough range, so a range of uids is ok for us.
>>
>> generating a user-.slice file for every user (or symlink them or
>> whatever) looks a bit cumbersome, and probably not really performance
>> friendly if the range is in eg 100k (possible) uids.
>>
>> e.g. if this range was 100k-200k, i was more looking for a way to do
>> e.g. user-1X.slice or user-10:20.slice
>>
>
> As far as I know there isn't a good systemd-native method for this, but
> you can dynamically set slice parameters during PAM processing, as in this
> blog post:
> https://utcc.utoronto.ca/~cks/space/blog/linux/Ubuntu1804SystemdUserLimits
>
> --
> Mantas Mikulėnas
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
[image: SMILE]  

20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique

[image: email] jeremy.ro...@smile.fr
[image: phone]  +33 6 88 25 87 42
[image: url] http://www.smile.eu

[image: Twitter]  [image: Facebook]
 [image: LinkedIn]
 [image: Github]


[image: Découvrez l’univers Smile, rendez-vous sur smile.eu]

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?

[Reindl Harald]

Am 29.09.19 um 12:08 schrieb Lennart Poettering:
> Who are you designing this for anyway? I mean, isn't Fedora dropping
> i386 support even these days, so that in particular the Fedora
> *desktop* becomes an x86-64 only thing (and thus an EFI-only thing)

seriously?

what has x86_64 only to do with EFI?

not a single i386 bit on any machine here for 10 years
not a single UEFI machine here at the same time
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?

[Lennart Poettering]

On Fr, 27.09.19 16:16, Hans de Goede (hdego...@redhat.com) wrote:

> 
>
> > Secondly, the boot loader specification (the original one, not the
> > weird templating/macro language fedora grub adopted) allows multiple
> > initrds to be specified, with any path you like (as long as it's
> > relative to $BOOT). > Hence, you can just just use a fixed path there
> > pointing to an initrd that is shared between all boot loader entries,
> > and then you don't need to regenerate anything, but this one initrd
> > file that is shared.
>
> Right, that is what this is about, regenerating the shared initrd
> when localed changes /etc/vconsole.conf. Since localed is the process
> modifying /etc/vconsole.conf, it should also trigger the regenerate of
> the shared initrd. If you do not like doing this through calling
> install-kernel, then I'm open to other suggestions for how localed
> can trigger / start the regeneration of the shared initrd.

It is made worse by regeneration of a shared initrd. Because if you do
that you *must* sign. If you instead define very specific, very
focussed one-value config files only, that you can validate easily
non-cryptographically, you don't need to sign. i.e. if you know for
sure that the worst thing that might happen if you don't sign the kbd
map config file is that you boot with a finnish keymap, then maybe
people can live with that.

> > Then, what about SecureBoot? I mean, do you intend to sign this second
> > initrd? Just overlaying an unverified unvalidated initrd above the
> > actual one is dangerous as it can be, there needs to be some
> > validation beforehand.
>
> Well ATM we do not verify the initrd at all, nor do we verify
> the kernel commandline. The commandline currently contains system
> specific info; and with your bootloader appends keymap argument
> proposal, would change on a keymap change. IOW it looks like we
> need some way to sign (with a local key) locally generated data,
> such as a shared config-initrd or the kernel commandline.
>
> This is a pre-existing problem which is not really made (much)
> worse by adding a config initrd.

I very much disagree. initrds can contain code. simple, one-value
config files or EFI vars do not.

> Thinking before sending patches is exactly why I started this discussion,
> so thank you for your input, but again please let go of the whole
> EFI only mindset it is very unhelpful and unproductive.

Well, please at least accept the lessons that EFI teaches you,
i.e. why and how people use EFI vars, and then maybe do the minimal
work on other systems to provide something remotely similar, using the
most appropriate storage technology those platforms support, using the
closest semantics and behaviour you can come up with.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?

[Lennart Poettering]

On Fr, 27.09.19 16:00, Hans de Goede (hdego...@redhat.com) wrote:

> Well until we make sure nothing ever writes outside of the user
> homedir security conscious users will likely still want to use

I am pretty sure the security conscious users should not run an OS
that writes user stuff all over the place, but only does so into
$HOME.

> full-disk encryption and there is also plenty of hw which Fedora
> supports which does not have a TPM2

Well, hw with fewer functions gets less functionality, and I am sure
this is not surprising to most users.

> > Which hence raises the question: isn't this something the boot loader
> > should manage initially, and then just pass to the kernel/initrd?
> > i.e. on EFI systems, shouldn't this just be an efi var, that the boot
> > ldr can read, and then pass on to the kernel (or alternatively, read
> > by the initrd?) Alternatively, if you care about non-EFI, isn't this
> > also something you want to tell the boot ldr about, and then have the
> > boot loader pass to the kernel, maybe via a struct boot_param entry?
> > (or simply by appending something to the kernel cmdline if that
> > doesn't fly).
>
> We definitely care about non EFI and we care about a scala on
> bootloaders, modifying them all for this really does not scale,
> so I believe we really need a solution outside of the bootloader
> and parallel to that we can think about also passing this info
> to the bootloader somehow.

Uhm, so given we lived with this issue for so long, and given it's
easy to fix on EFI in a clean and elegant way, don't you thinkg that
it wouldn't be acceptable to fix it for EFI only for now? I mean,
people who run fedora *desktops* on non-EFI hw are probably a small
enough number of people to allow this to remain unfixed a bit longer?

Who are you designing this for anyway? I mean, isn't Fedora dropping
i386 support even these days, so that in particular the Fedora
*desktop* becomes an x86-64 only thing (and thus an EFI-only thing).

Anyway, even if you insist that the Fedora desktop should care about
non-EFI, which I can accept, isn't the lesson to learn to add some
concept like EFI vars to those archs too? i.e. apparently OSes and
boot loaders want to communicate, so why not make that happen on those
archs too? I mean, the concept of EFI vars is simple and semantically
it's not even essential to have NVRAM to store them in — a fact to
which the EFI firmware typically used by qemu/kvm is document, as it
actually stores those EFI vars in the ESP, so that they are included
in the VM image.

i.e maybe write down a spec, that declares how to store settings
shared between host OS, boot loader and early-boot kernel environment
on systems that have no EFI NVRAM, and then we can make use of
that. i.e. come up with semantics inspired by the boot loader spec for
finding the boot partition to use, then define a couple of files in
there for these params.

In fact, sd-boot nowadays stores the boot-time random seed it manages
to initialize the kernel's entropy pool with in
$BOOT/loader/random-seed. It would only be natural to build on that,
and introduce $BOOT/loader/kbdmap and so on.

i.e. generating initrd images with cpio and so on is hacky, gluey,
Linux-specific. If you just use plain simple, standardized config
files at clearly defined locations, then reading and writing them is
simple, they can be shared between all players, are not Linux specific
and so on. I think systemd could certainly commit to updating those
files then.

Putting together such a spec isn't difficult even. Could be as short
as:

"This spec builds on the boot loader spec. The keyboard map is
stored in $BOOT/loader/kbdmap, using ISO-3166-1 alpha-2
country codes. We suggest boot loaders use this for their own
key maps, and pass it to the OS, for example via the kernel
command line."

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] TPMs on Linux (was Re: Make systemd-localed modify the kernel commandline for the initrd keymap?)

[Lennart Poettering]

On Fr, 27.09.19 19:26, Mantas Mikulėnas (graw...@gmail.com) wrote:

> > That's the main problem. Only two of my several still-reasonably-modern
> > x64 machines have TPMs, and one of them is TPM 1.2 which requires the
> > completely unmaintained Trousers stack.
>
> As a side topic for systemd-homed, I kind of wish Linux had some actual
> daemon that would take care of TPM stuff, like providing an API to
> seal

A small clarification: systemd-homed does not interface with the
TPM. I am pretty sure it shouldn't. I think linking your OS storage to
the TPM makes sense, but the user's data store not so much.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel