Re: [systemd-devel] Minimize systemd for kdump's initramfs

2020-01-02 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Jan 03, 2020 at 11:48:53AM +0800, Dave Young wrote:
> On 01/03/20 at 11:45am, Dave Young wrote:
> > On 01/02/20 at 09:02am, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote:
> > > > Some component, like Systemd, have grown by a lot, here is a list of
> > > > the size of part of binaries along with the binaries they required in
> > > > F31:
> > > > /root/image/bin/systemctl
> > > > 20M .
> > > > /root/image/usr/bin/systemctl
> > > > 20M .
> > > > /root/image/usr/bin/systemd-cgls
> > > > 20M .
> > > > /root/image/usr/bin/systemd-escape
> > > > 20M .
> > > > /root/image/usr/bin/systemd-run
> > > > 20M .
> > > > ...
> > > > 
> > > > There are overlays between the libraries they used so when installed
> > > > into the initramfs, the total size didn't go too big yet. But we can
> > > > see the size of systemd binary and libraries it used is much bigger
> > > > than others.
> > > 
> > > All systemd binaries will mostly link to the same libraries (because
> > > they link to a private shared library, which links to various other
> > > shared libraries). So this "20M" will be repeated over and over, but
> > > it's the same dependencies.
> > > 
> > > While we'd all prefer for this to be smaller, 20M should is actually
> > > not that much...
> > > 
> > > > And as a compare, from version 219 to 243, systemd's library
> > > > dependency increased a lot:
> > > > (v219 is 5M in total, v243 is 20M in total)
> > > 
> > > This is slightly misleading. Code was moved from individual binaries
> > > to libsystemd-shared-nnn.so, so if you look at the deps of just a single
> > > binary, you'll see many more deps (because libsystemd-shared-nnn.so has
> > > more deps). But the total number of deps when summed over all binaries
> > > grew much less. A more useful measure would be the size with deps summed
> > > over all systemd binaries that are installed into your image in v219 and
> > > v243.
> > > 
> > 
> > I vaguely remember the size increased before due to linking with libidn2
> > previously, so those libraries contribute a lot.
> > 
> > Does every systemd binary depend on all libraries? Or each of the
> > systemd binary only depends on those libs when really needed?
> 
> For example if I do not need journalctl, then I can drop journalctl and
> those libraries specific for journalctl?

It's using standard shared object linking, so yeah, for anything which
libsystemd-shared-nnn.so links to, "every systemd binary depend[s] on
all libraries", in the sense that the runtime linker will fail to start
the executable if any of the libraries are missing.

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


Re: [systemd-devel] Minimize systemd for kdump's initramfs

2020-01-02 Thread Kairui Song
On Thu, Jan 2, 2020 at 5:04 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote:
> > Some component, like Systemd, have grown by a lot, here is a list of
> > the size of part of binaries along with the binaries they required in
> > F31:
> > /root/image/bin/systemctl
> > 20M .
> > /root/image/usr/bin/systemctl
> > 20M .
> > /root/image/usr/bin/systemd-cgls
> > 20M .
> > /root/image/usr/bin/systemd-escape
> > 20M .
> > /root/image/usr/bin/systemd-run
> > 20M .
> > ...
> >
> > There are overlays between the libraries they used so when installed
> > into the initramfs, the total size didn't go too big yet. But we can
> > see the size of systemd binary and libraries it used is much bigger
> > than others.
>
> All systemd binaries will mostly link to the same libraries (because
> they link to a private shared library, which links to various other
> shared libraries). So this "20M" will be repeated over and over, but
> it's the same dependencies.
>
> While we'd all prefer for this to be smaller, 20M should is actually
> not that much...
>
> > And as a compare, from version 219 to 243, systemd's library
> > dependency increased a lot:
> > (v219 is 5M in total, v243 is 20M in total)
>
> This is slightly misleading. Code was moved from individual binaries
> to libsystemd-shared-nnn.so, so if you look at the deps of just a single
> binary, you'll see many more deps (because libsystemd-shared-nnn.so has
> more deps). But the total number of deps when summed over all binaries
> grew much less. A more useful measure would be the size with deps summed
> over all systemd binaries that are installed into your image in v219 and
> v243.
>

Yes, you are right.

I use following method to measure the size of the binary together with
the library it used:
Just call dracut-install to install a binary into an empty folder as
new root, that tool can also take care of resolve and installing the
libraries. The result it like this:

With systemd V243:
[root@localhost test]# for i in /usr/bin/systemd-*; do
/usr/lib/dracut/dracut-install -l -D $(pwd) $i; done
[root@localhost test]# for i in /lib/systemd/systemd-*; do
/usr/lib/dracut/dracut-install -l -D $(pwd) $i; done
[root@localhost test]# /usr/lib/dracut/dracut-install -l -D $(pwd)
/lib/systemd/systemd
[root@localhost test]# /usr/lib/dracut/dracut-install -l -D $(pwd)
/usr/bin/journalctl
[root@localhost test]# /usr/lib/dracut/dracut-install -l -D $(pwd)
/usr/bin/loginctl
[root@localhost test]# /usr/lib/dracut/dracut-install -l -D $(pwd)
/usr/bin/systemctl
[root@localhost test]# /usr/lib/dracut/dracut-install -l -D $(pwd)
/usr/bin/udevadm
[root@localhost test]# du -hs .
34M .

With V219:
[root@localhost test]# for i in /usr/bin/systemd-*; do
/usr/lib/dracut/dracut-install -l -D $(pwd) $i; done
[root@localhost test]# for i in /usr/lib/systemd/systemd-*; do
/usr/lib/dracut/dracut-install -l -D $(pwd) $i; done
[root@localhost test]# /usr/lib/dracut/dracut-install -l -D $(pwd)
/usr/lib/systemd/systemd
[root@localhost test]# /usr/lib/dracut/dracut-install -l -D $(pwd)
/usr/bin/journalctl
[root@localhost test]# /usr/lib/dracut/dracut-install -l -D $(pwd)
/usr/bin/loginctl
[root@localhost test]# /usr/lib/dracut/dracut-install -l -D $(pwd)
/usr/bin/systemctl
[root@localhost test]# /usr/lib/dracut/dracut-install -l -D $(pwd)
/usr/bin/udevadm
[root@localhost test]# du -hs .
33M .


So indeed it didn't grow in total.
But kdump's initramfs only need a subset of all binaries, so if I only
install the files needed:


With V243:
[root@localhost test]# for i in systemd systemd-coredump
systemd-cgroups-agent systemd-shutdown systemd-reply-password
systemd-fsck systemd-udevd systemd-journald systemd-sysctl
systemd-modules-load systemd-vconsole-setup; do
/usr/lib/dracut/dracut-install -l -D $(pwd) /usr/lib/systemd/$i; done
[root@localhost test]#
[root@localhost test]# for i in journalctl systemctl udevadm
systemd-run systemd-escape systemd-cgls systemd-tmpfiles; do
/usr/lib/dracut/dracut-install -l -D $(pwd) /usr/bin/$i; done
[root@localhost test]# du -hs .
24M .

With V219:
[root@localhost test]# for i in systemd systemd-coredump
systemd-cgroups-agent systemd-shutdown systemd-reply-password
systemd-fsck systemd-udevd systemd-journald systemd-sysctl
systemd-modules-load systemd-vconsole-setup; do
/usr/lib/dracut/dracut-install -l -D $(pwd) /usr/lib/systemd/$i; done
[root@localhost test]# for i in journalctl systemctl udevadm
systemd-run systemd-escape systemd-cgls systemd-tmpfiles; do
/usr/lib/dracut/dracut-install -l -D $(pwd) /usr/bin/$i; done
[root@localhost test]# du -hs .
12M .

That did grow a lot.

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


Re: [systemd-devel] Minimize systemd for kdump's initramfs

2020-01-02 Thread Dave Young
On 01/03/20 at 11:45am, Dave Young wrote:
> On 01/02/20 at 09:02am, Zbigniew Jędrzejewski-Szmek wrote:
> > On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote:
> > > Some component, like Systemd, have grown by a lot, here is a list of
> > > the size of part of binaries along with the binaries they required in
> > > F31:
> > > /root/image/bin/systemctl
> > > 20M .
> > > /root/image/usr/bin/systemctl
> > > 20M .
> > > /root/image/usr/bin/systemd-cgls
> > > 20M .
> > > /root/image/usr/bin/systemd-escape
> > > 20M .
> > > /root/image/usr/bin/systemd-run
> > > 20M .
> > > ...
> > > 
> > > There are overlays between the libraries they used so when installed
> > > into the initramfs, the total size didn't go too big yet. But we can
> > > see the size of systemd binary and libraries it used is much bigger
> > > than others.
> > 
> > All systemd binaries will mostly link to the same libraries (because
> > they link to a private shared library, which links to various other
> > shared libraries). So this "20M" will be repeated over and over, but
> > it's the same dependencies.
> > 
> > While we'd all prefer for this to be smaller, 20M should is actually
> > not that much...
> > 
> > > And as a compare, from version 219 to 243, systemd's library
> > > dependency increased a lot:
> > > (v219 is 5M in total, v243 is 20M in total)
> > 
> > This is slightly misleading. Code was moved from individual binaries
> > to libsystemd-shared-nnn.so, so if you look at the deps of just a single
> > binary, you'll see many more deps (because libsystemd-shared-nnn.so has
> > more deps). But the total number of deps when summed over all binaries
> > grew much less. A more useful measure would be the size with deps summed
> > over all systemd binaries that are installed into your image in v219 and
> > v243.
> > 
> 
> I vaguely remember the size increased before due to linking with libidn2
> previously, so those libraries contribute a lot.
> 
> Does every systemd binary depend on all libraries? Or each of the
> systemd binary only depends on those libs when really needed?

For example if I do not need journalctl, then I can drop journalctl and
those libraries specific for journalctl?

> 
> Thanks
> Dave

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


Re: [systemd-devel] Minimize systemd for kdump's initramfs

2020-01-02 Thread Dave Young
On 01/02/20 at 09:02am, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote:
> > Some component, like Systemd, have grown by a lot, here is a list of
> > the size of part of binaries along with the binaries they required in
> > F31:
> > /root/image/bin/systemctl
> > 20M .
> > /root/image/usr/bin/systemctl
> > 20M .
> > /root/image/usr/bin/systemd-cgls
> > 20M .
> > /root/image/usr/bin/systemd-escape
> > 20M .
> > /root/image/usr/bin/systemd-run
> > 20M .
> > ...
> > 
> > There are overlays between the libraries they used so when installed
> > into the initramfs, the total size didn't go too big yet. But we can
> > see the size of systemd binary and libraries it used is much bigger
> > than others.
> 
> All systemd binaries will mostly link to the same libraries (because
> they link to a private shared library, which links to various other
> shared libraries). So this "20M" will be repeated over and over, but
> it's the same dependencies.
> 
> While we'd all prefer for this to be smaller, 20M should is actually
> not that much...
> 
> > And as a compare, from version 219 to 243, systemd's library
> > dependency increased a lot:
> > (v219 is 5M in total, v243 is 20M in total)
> 
> This is slightly misleading. Code was moved from individual binaries
> to libsystemd-shared-nnn.so, so if you look at the deps of just a single
> binary, you'll see many more deps (because libsystemd-shared-nnn.so has
> more deps). But the total number of deps when summed over all binaries
> grew much less. A more useful measure would be the size with deps summed
> over all systemd binaries that are installed into your image in v219 and
> v243.
> 

I vaguely remember the size increased before due to linking with libidn2
previously, so those libraries contribute a lot.

Does every systemd binary depend on all libraries? Or each of the
systemd binary only depends on those libs when really needed?

Thanks
Dave

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


Re: [systemd-devel] Minimize systemd for kdump's initramfs

2020-01-02 Thread Adam Williamson
On Thu, 2020-01-02 at 22:59 +, Zbigniew Jędrzejewski-Szmek wrote:

> (In Debian the motivation was speed, rather than installation footprint.
> So that work was mostly wasted because of the switch from sysvinit to systemd
> and ensuing avoidance of shell during boot. Instead of trying to switch
> shells, we should instead try to avoid shell in boot as much as possible.)

this may be tricky since dracut is just a giant ball of shell scripts
that no-one likes to touch...:P
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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


Re: [systemd-devel] Minimize systemd for kdump's initramfs

2020-01-02 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Jan 02, 2020 at 03:29:26PM -0500, Robbie Harwood wrote:
> Kairui Song  writes:
> 
> > What I'm trying to do is reduce the initramfs size used for kdump.
> > Kdump loads a crash kernel and kdump initramfs image in a prereseved
> > memory region, which get booted when current kernel crashed and
> > perform crash dump. The prereserved memory is limited, so initramfs
> > shouldn't go too big.
> >
> > Kdump in Fedora use Dracut to create bootable initramfs, just hook the
> > final step to do kdump things instead of switch root. And to reduce
> > the size only the binaries and drivers required to boot and perform
> > kdump on current machine is installed. So long it have been working
> > very well.
> >
> > But problem is Dracut works by reusing binaries and libraries from the
> > currently running system, and many userspace binaries and libraries is
> > keep growing and using more space. So the initramfs is also growing.
> >
> > /root/image/bin/bash
> > 4.8M.
> > /root/image/bin/sh
> > 4.8M.
> 
> So it's not a direct comparison, but:
> 
> $ du -sh /bin/bash /bin/dash
> 1.2M /bin/bash
> 132K /bin/dash
> 
> This suggests to me that 1-3 MB could be reduced by using dash as the
> shell.  (dash's library dependencies are also smaller since it drops
> requirements on libtinfo (200K) and libdl (36K); whether this matters I
> don't know.)

dash doesn't support various bash extensions and syntaxes. The problem
is that many scripts which use #!/bin/sh really require #!/bin/bash.
So after switching to dash as the provider of /bin/sh various scripts
would suddenly behave differently, and those bugs would only be detected
at runtime.

Debian went through a long process of switching to dash as the default
init shell and fixing various scripts to remove bashisms so things
would run on dash (or any other /bin/sh). This was way more work than
anyone excepted and took a long time. IMO the gain of 1 MB that we
would get is not nearly enough to offset the work required and the
destabilization.

(In Debian the motivation was speed, rather than installation footprint.
So that work was mostly wasted because of the switch from sysvinit to systemd
and ensuing avoidance of shell during boot. Instead of trying to switch
shells, we should instead try to avoid shell in boot as much as possible.)

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


Re: [systemd-devel] systemd unit file to remount /home /tmp /dev/shm /run with nosuid, nodev

2020-01-02 Thread Topi Miettinen

On 2.1.2020 21.08, Josh Triplett wrote:

Lennart Poettering wrote:

And noexec doesn't really make much sense for these dirs, as this
blocks mmap() with MAP_EXEC and there are plenty apps that want to use
that. Moreover "noexec" is at best a protection against accidental
execution and not a security mechanism since it is trivially easy to
circumvent (just call the interpreter directly with the file to
execute as first arg, which for ELF means "/lib64/ld-linux-x86-64.so.2 $BINARY")


That workaround doesn't actually work anymore; the former (blocking mmap
with MAP_EXEC) exists specifically to protect against the latter
(running the interpreter directly).

$ mount | grep '/run '
tmpfs on /run type tmpfs 
(rw,nosuid,nodev,noexec,relatime,size=1620848k,mode=755)
$ sudo cp -a /bin/ls /run/ls
$ /run/ls
bash: /run/ls: Permission denied
(126) $ /lib64/ld-linux-x86-64.so.2 /run/ls
/run/ls: error while loading shared libraries: /run/ls: failed to map segment 
from shared object
(127) $

It's theoretically possible to work around *that* if you have permission
to run arbitrary code and to remap memory from write to execute (both of
which might also be locked down). But even without that, mount -o noexec
does meaningfully improve security, and the trivial workaround no longer
works.


It's not theoretical at all. You can use memfd_create() to prepare a 
file without it ever going to disk and then use 
mmap(,,PROT_EXEC|PROT_READ,,) to put it into address space for execution.


Seccomp can be used to block memfd_create() but then some programs want 
to use it, so it can't be blocked globally. SELinux PROCESS__EXECMEM 
check may also be able to stop this, I haven't tried.


But then many interpreters (designed as such or accidentally 
Turing-complete decoders) can also be used to go around all these file 
system level checks.


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


Re: [systemd-devel] Minimize systemd for kdump's initramfs

2020-01-02 Thread Robbie Harwood
Kairui Song  writes:

> What I'm trying to do is reduce the initramfs size used for kdump.
> Kdump loads a crash kernel and kdump initramfs image in a prereseved
> memory region, which get booted when current kernel crashed and
> perform crash dump. The prereserved memory is limited, so initramfs
> shouldn't go too big.
>
> Kdump in Fedora use Dracut to create bootable initramfs, just hook the
> final step to do kdump things instead of switch root. And to reduce
> the size only the binaries and drivers required to boot and perform
> kdump on current machine is installed. So long it have been working
> very well.
>
> But problem is Dracut works by reusing binaries and libraries from the
> currently running system, and many userspace binaries and libraries is
> keep growing and using more space. So the initramfs is also growing.
>
> /root/image/bin/bash
> 4.8M.
> /root/image/bin/sh
> 4.8M.

So it's not a direct comparison, but:

$ du -sh /bin/bash /bin/dash
1.2M /bin/bash
132K /bin/dash

This suggests to me that 1-3 MB could be reduced by using dash as the
shell.  (dash's library dependencies are also smaller since it drops
requirements on libtinfo (200K) and libdl (36K); whether this matters I
don't know.)

Thanks,
--Robbie


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


Re: [systemd-devel] systemd unit file to remount /home /tmp /dev/shm /run with nosuid, nodev

2020-01-02 Thread Josh Triplett
Lennart Poettering wrote:
> And noexec doesn't really make much sense for these dirs, as this
> blocks mmap() with MAP_EXEC and there are plenty apps that want to use
> that. Moreover "noexec" is at best a protection against accidental
> execution and not a security mechanism since it is trivially easy to
> circumvent (just call the interpreter directly with the file to
> execute as first arg, which for ELF means "/lib64/ld-linux-x86-64.so.2 
> $BINARY")

That workaround doesn't actually work anymore; the former (blocking mmap
with MAP_EXEC) exists specifically to protect against the latter
(running the interpreter directly).

$ mount | grep '/run '
tmpfs on /run type tmpfs 
(rw,nosuid,nodev,noexec,relatime,size=1620848k,mode=755)
$ sudo cp -a /bin/ls /run/ls
$ /run/ls
bash: /run/ls: Permission denied
(126) $ /lib64/ld-linux-x86-64.so.2 /run/ls
/run/ls: error while loading shared libraries: /run/ls: failed to map segment 
from shared object
(127) $

It's theoretically possible to work around *that* if you have permission
to run arbitrary code and to remap memory from write to execute (both of
which might also be locked down). But even without that, mount -o noexec
does meaningfully improve security, and the trivial workaround no longer
works.

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


Re: [systemd-devel] Random branch in github.com/systemd/systemd

2020-01-02 Thread František Šumšal
On 1/2/20 5:13 PM, Mike Gilbert wrote:
> On Thu, Jan 2, 2020 at 9:08 AM Lennart Poettering
>  wrote:
>>> If possible, it would probably be wise to restrict access for pushing
>>> new branches like this.
>>
>> Hmm, how would we do that? Any suggestion? Happy to restrict that, but
>> not sure how to do that...
> 
> I thought maybe there was a setting in github for it, or maybe
> something to do with permissions?
> 
> I don't manage any multi-user github repos myself, so I don't have any
> tangible advice.

This is actually kinda hard, as there is (right now) no configuration option
to restrict creation of new branches.

In theory, we could 'abuse' branch protection rules[0] (which currently protect
the master branch against force pushes), but the branch pattern is not flexible
enough to manage that, precisely the `File.fnmatch()` function[1] it uses 
internally
doesn't have any negation logic to include all branches except for `master`.

I guess we could do something like this[2], which would cover most of the branch
names, in combination with some protection rule (either 'Require pull request 
reviews before merging' or 'Restrict who can push to matching branches'), but
it's not perfect.

[0] 
https://help.github.com/en/github/administering-a-repository/configuring-protected-branches
[1] https://ruby-doc.org/core-2.5.1/File.html#method-c-fnmatch
[2] 
https://stackoverflow.com/questions/55053460/github-branch-name-pattern-negation/55057727#55057727

-- 
PGP Key ID: 0xFB738CE27B634E4B



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Random branch in github.com/systemd/systemd

2020-01-02 Thread Mike Gilbert
On Thu, Jan 2, 2020 at 9:08 AM Lennart Poettering
 wrote:
> > If possible, it would probably be wise to restrict access for pushing
> > new branches like this.
>
> Hmm, how would we do that? Any suggestion? Happy to restrict that, but
> not sure how to do that...

I thought maybe there was a setting in github for it, or maybe
something to do with permissions?

I don't manage any multi-user github repos myself, so I don't have any
tangible advice.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Random branch in github.com/systemd/systemd

2020-01-02 Thread Lennart Poettering
On So, 29.12.19 14:59, Mike Gilbert (flop...@gentoo.org) wrote:

> It looks like a branch called "msekletar-security-list-process" was
> pushed to the official systemd github repo earlier this month. This
> branch probably belongs in msekletar's personal fork instead.
>
> https://github.com/systemd/systemd/branches

Indeed. Deleted now.

> If possible, it would probably be wise to restrict access for pushing
> new branches like this.

Hmm, how would we do that? Any suggestion? Happy to restrict that, but
not sure how to do that...

Lennart

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


Re: [systemd-devel] systemd unit file to remount /home /tmp /dev/shm /run with nosuid, nodev

2020-01-02 Thread Lennart Poettering
On Mo, 30.12.19 12:26, Mantas Mikulėnas (graw...@gmail.com) wrote:

> > a script to remount /home /tmp /dev/shm /run (configurable) with
> > nosuid,nodev (+noexec configurable) has been created by me. The purpose
> > of remounting is increasing the security of the system. The script shall
> > run as early as reasonably possible during boot.
> >
> > The systemd unit file [1] and script [2] attached below in a simplified
> > version or links to actual version. [3] [4] This is planned to be
> > enabled by default in a Debian derivative Linux distribution.
> >
>
> On a standard Debian system, the three tmpfs mounts (/run, /tmp, /dev/shm)
> *already have* the nosuid and nodev options – this is hardcoded in
> mount-setup.c. So you should first figure out why they are not present in
> your case to begin with.

And noexec doesn't really make much sense for these dirs, as this
blocks mmap() with MAP_EXEC and there are plenty apps that want to use
that. Moreover "noexec" is at best a protection against accidental
execution and not a security mechanism since it is trivially easy to
circumvent (just call the interpreter directly with the file to
execute as first arg, which for ELF means "/lib64/ld-linux-x86-64.so.2 $BINARY")

I mean, we'd set it by default if it worked and if it would lock
things down, but unfortunately it does neither really...

> All mounts exist as .mount units, so they can be overridden by custom
> .mount units and .mount.d/ drop-ins, similar to services.

/run and /dev/shm are considered "API" mounts, i.e. systemd mounts
them internally, and doesn't expose .mount units for them.

Lennart

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


Re: [systemd-devel] Cannot create 'home' directory systemd-tmpfiles-setup.service

2020-01-02 Thread Lennart Poettering
On Mo, 30.12.19 18:57, Bao Nguyen (bao...@gmail.com) wrote:

> Hi everyone,
>
> systemd-tmpfiles-setup.service throws a strange error when booting
> my system

Which distro? Which systemd version?

> Dec 30 11:32:53 mynode systemd-tmpfiles[751]: Failed to open directory
> 'home': No such file or directory

Please have a closer look at your /home? i.e. is it a symlink or so?
or even a chain?

Lennart

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


Re: [systemd-devel] systemd kills user's scopes/sessions before shutdown service

2020-01-02 Thread Lennart Poettering
On Di, 31.12.19 11:04, Kamal Rathi (kr30ap...@gmail.com) wrote:

> Hi Git-Hub Mailing List,
>
> I am designing a stop service which has to be run before the kill of user's
> scope / session .

How could this work? Users can log out or be terminated any time,
i.e. their scope/sessions can go away during runtime all the time, and
they won't tell us beforehand about it beforehand, hence how could we
run something beforehand?

Lennart

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


Re: [systemd-devel] systemd kills user's scopes/sessions before shutdown service

2020-01-02 Thread Andrei Borzenkov
31.12.2019 08:34, Kamal Rathi пишет:
> Hi Git-Hub Mailing List,
> 
> I am designing a stop service which has to be run before the kill of user's
> scope / session .
> As the reboot or shutdown are being initiated the systemd kill all the
> users which are in user's.slice
> before the script ran so the script is of no use if the user session are
> killed first then the stop.service
> stop.service
> 
> [Unit]
> Description=Service to auto stop the EBS application
> DefaultDependencies=no
> Before=shutdown.target
> RefuseManualStart=true
> 
> [Service]
> Type=oneshot
> ExecStart=/startdb/stop/stop.sh
> 
> [Install]
> WantedBy=shutdown.target reboot.target
> 

This cannot work. systemd first stops everything then starts shutdown
target. Your unit is only pulled in at the moment shutdown target is
started.

> 
> https://github.com/systemd/systemd/issues/14318
> 

You have been told there how it should be done properly. What is the
point to start your question here with the same non-working variant?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Minimize systemd for kdump's initramfs

2020-01-02 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote:
> Some component, like Systemd, have grown by a lot, here is a list of
> the size of part of binaries along with the binaries they required in
> F31:
> /root/image/bin/systemctl
> 20M .
> /root/image/usr/bin/systemctl
> 20M .
> /root/image/usr/bin/systemd-cgls
> 20M .
> /root/image/usr/bin/systemd-escape
> 20M .
> /root/image/usr/bin/systemd-run
> 20M .
> ...
> 
> There are overlays between the libraries they used so when installed
> into the initramfs, the total size didn't go too big yet. But we can
> see the size of systemd binary and libraries it used is much bigger
> than others.

All systemd binaries will mostly link to the same libraries (because
they link to a private shared library, which links to various other
shared libraries). So this "20M" will be repeated over and over, but
it's the same dependencies.

While we'd all prefer for this to be smaller, 20M should is actually
not that much...

> And as a compare, from version 219 to 243, systemd's library
> dependency increased a lot:
> (v219 is 5M in total, v243 is 20M in total)

This is slightly misleading. Code was moved from individual binaries
to libsystemd-shared-nnn.so, so if you look at the deps of just a single
binary, you'll see many more deps (because libsystemd-shared-nnn.so has
more deps). But the total number of deps when summed over all binaries
grew much less. A more useful measure would be the size with deps summed
over all systemd binaries that are installed into your image in v219 and
v243.

I don't have a link at hand, but there's work being done to use openssl
for all crypto, which would reduce the dependency list nicely.

> Is there any way to have a smaller systemd binary that is just enough
> to boot the initramfs into the stage before switch-root?

We don't have anything like this now, sorry!

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