Bug#775613: systemd: why is /run/systemd/inhibit/1.ref inherited?
Package: systemd
Version: 215-9
Severity: normal
type=AVC msg=audit(1421538903.417:232): avc: denied { use } for pid=23546
comm="kded4" path="/run/systemd/inhibit/1.ref" dev="tmpfs" ino=91124
scontext=rjc:user_r:user_t:s0-s0:c0.c1023
tcontext=system_u:system_r:systemd_logind_t:s0 tclass=fd permissive=0
When I login via kdm the KDE user processes (and presumably user processes
from any other desktop environment) inherit /run/systemd/inhibit/1.ref.
Is this desired? If so why? I have SE Linux preventing it and everything
works.
-- Package-specific info:
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages systemd depends on:
ii acl 2.2.52-2
ii adduser 3.113+nmu3
ii initscripts 2.88dsf-58
ii libacl1 2.2.52-2
ii libaudit1 1:2.4-1+b1
ii libblkid1 2.25.2-4
ii libc6 2.19-13
ii libcap2 1:2.24-6
ii libcap2-bin 1:2.24-6
ii libcryptsetup4 2:1.6.6-4
ii libgcrypt20 1.6.2-4+b1
ii libkmod218-3
ii liblzma55.1.1alpha+20120614-2+b3
ii libpam0g1.1.8-3.1
ii libselinux1 2.3-2
ii libsystemd0 215-9
ii mount 2.25.2-4
ii sysv-rc 2.88dsf-58
ii udev215-9
ii util-linux 2.25.2-4
Versions of packages systemd recommends:
ii dbus1.8.14-1
ii libpam-systemd 215-9
Versions of packages systemd suggests:
pn systemd-ui
-- Configuration Files:
/etc/systemd/journald.conf changed:
[Journal]
SystemMaxUse=25M
-- no debconf information
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#775651: systemd: /run/user/$UID directories are created with type tmpfs_t on SE Linux
Package: systemd
Version: 215-9
Severity: normal
# grep auditallow local.te
auditallow domain tmpfs_t:dir create;
# grep granted /var/log/audit/audit.log
type=AVC msg=audit(1421563773.398:239): avc: granted { create } for pid=4302
comm="systemd" name="systemd" scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
type=AVC msg=audit(1421563773.398:240): avc: granted { create } for pid=4302
comm="systemd" name="generator" scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
type=AVC msg=audit(1421563773.398:241): avc: granted { create } for pid=4302
comm="systemd" name="generator.early" scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
type=AVC msg=audit(1421563773.398:242): avc: granted { create } for pid=4302
comm="systemd" name="generator.late" scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
# ls -laZ /run/user
total 0
drwxr-xr-x. 4 root root system_u:object_r:var_auth_t:SystemLow 80 Jan 18
17:58 .
drwxr-xr-x. 26 root root system_u:object_r:var_run_t:SystemLow 1080 Jan 18
17:58 ..
drwx--. 3 root root system_u:object_r:var_auth_t:SystemLow 60 Jan 18
17:34 0
drwx--. 3 rjc rjc system_u:object_r:tmpfs_t:SystemLow 60 Jan 18
17:58 1001
I have an auditallow rule to audit creation of tmpfs_t directories. As you can
see systemd creates such directories when I login. The directory "0" has the
correct context because I ran "restorecon" but the directory "1001" has the
wrong context because I just logged in as that user.
There are no auto trans rules to give it the type tmpfs_t and the file_contexts
also specify var_auth_t. I think that systemd is requesting tmpfs_t as the
type.
-- Package-specific info:
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages systemd depends on:
ii acl 2.2.52-2
ii adduser 3.113+nmu3
ii initscripts 2.88dsf-58
ii libacl1 2.2.52-2
ii libaudit1 1:2.4-1+b1
ii libblkid1 2.25.2-4
ii libc6 2.19-13
ii libcap2 1:2.24-6
ii libcap2-bin 1:2.24-6
ii libcryptsetup4 2:1.6.6-4
ii libgcrypt20 1.6.2-4+b1
ii libkmod218-3
ii liblzma55.1.1alpha+20120614-2+b3
ii libpam0g1.1.8-3.1
ii libselinux1 2.3-2
ii libsystemd0 215-9
ii mount 2.25.2-4
ii sysv-rc 2.88dsf-58
ii udev215-9
ii util-linux 2.25.2-4
Versions of packages systemd recommends:
ii dbus1.8.14-1
ii libpam-systemd 215-9
Versions of packages systemd suggests:
pn systemd-ui
-- Configuration Files:
/etc/systemd/journald.conf changed:
[Journal]
SystemMaxUse=25M
-- no debconf information
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#775651: systemd: /run/user/$UID directories are created with type tmpfs_t on SE Linux
On Mon, 19 Jan 2015, Michael Biebl wrote: > unfortunately I don't have any selinux knowledge at all, so I don't have > the slightest idea how this (or your earlier bug #775613) should be > addressed. > > Help is most welcome. Would you like me to give you root access on a virtual machine that demonstrates the bugs in question? -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: [DSE-Dev] Bug#796693: selinux-basics: Has init script in runlevel S but no matching service file
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796693 What do you suggest that we do in regard to this bug? The problem we have is that this isn't like your typical service script (most of which start daemons etc). It has more in common with a fsck than any other operation on a non-SE system. For correct operation the script has to relabel all files (if requested) and then reboot afterwards. It should run before any daemons are started as such daemons might run with the wrong security context which could prevent them from performing their normal functions and/or allow them to access sensitive data. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#800417: systemd: leaks a unix stream socket file handle
Package: systemd
Version: 215-17+deb8u2
Severity: minor
The following lines from the output of dmesg show that systemd (init_t) is
leaking socket file handle 7748 when spawning kmod. It should either close the
file handle before calling exec() or set FD_CLOEXEC.
In this case it's a minor bug (mostly an annoyance for me when writing SE
Linux policy) but in other situations such bugs can have security implications
so I won't write policy to hide this.
I can give you root access to a virtual machine demonstrating this problem if
it's of use to you.
[2.809497] audit: type=1400 audit(1443503644.476:4): avc: denied { read
write } for pid=151 comm="kmod" path="socket:[7748]" dev="sockfs" ino=7748
scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:system_r:init_t:s0
tclass=unix_stream_socket permissive=0
[2.809564] audit: type=1400 audit(1443503644.476:4): avc: denied { read
write } for pid=151 comm="kmod" path="socket:[7748]" dev="sockfs" ino=7748
scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:system_r:init_t:s0
tclass=unix_stream_socket permissive=0
-- System Information:
Debian Release: 8.2
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.1.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages systemd depends on:
ii acl 2.2.52-2
ii adduser 3.113+nmu3
ii initscripts 2.88dsf-59
ii libacl1 2.2.52-2
ii libaudit1 1:2.4-1+b1
ii libblkid1 2.25.2-6
ii libc6 2.19-18+deb8u1
ii libcap2 1:2.24-8
ii libcap2-bin 1:2.24-8
ii libcryptsetup4 2:1.6.6-5
ii libgcrypt20 1.6.3-2
ii libkmod218-3
ii liblzma55.1.1alpha+20120614-2+b3
ii libpam0g1.1.8-3.1
ii libselinux1 2.3-2
ii libsystemd0 215-17+deb8u2
ii mount 2.25.2-6
ii sysv-rc 2.88dsf-59
ii udev215-17+deb8u2
ii util-linux 2.25.2-6
Versions of packages systemd recommends:
pn dbus
pn libpam-systemd
Versions of packages systemd suggests:
pn systemd-ui
-- no debconf information
--
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#725357: SE Linux + systemd is a likely combination
As systemd is the default init in Jessie it's expected that most SE Linux systems running Debian will be affected. I have been running systemd on most of my servers since Wheezy. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#775613: systemd: why is /run/systemd/inhibit/1.ref inherited?
On Thu, 1 Oct 2015 08:00:45 AM Michael Biebl wrote:
> On Sun, 18 Jan 2015 11:07:40 +1100 Russell Coker
> wrote:
> > Package: systemd
> > Version: 215-9
> > Severity: normal
> >
> >
> > type=AVC msg=audit(1421538903.417:232): avc: denied { use } for
> > pid=23546 comm="kded4" path="/run/systemd/inhibit/1.ref" dev="tmpfs"
> > ino=91124 scontext=rjc:user_r:user_t:s0-s0:c0.c1023
> > tcontext=system_u:system_r:systemd_logind_t:s0 tclass=fd permissive=0
> >
> > When I login via kdm the KDE user processes (and presumably user
> > processes from any other desktop environment) inherit
> > /run/systemd/inhibit/1.ref.
> >
> > Is this desired? If so why? I have SE Linux preventing it and
> > everything works.
>
> I'm not sure what the problem is here.
> Can you elaborate?
If a socket or pipe is inherited from a system process to a process running as
a user there is a possibility of a security problem. Generally if there is no
reason for such access to be granted then it should not be granted. The file
handle could be closed before exec or it could be set to close on exec.
--
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#800417: systemd: leaks a unix stream socket file handle
On Thu, 1 Oct 2015 12:59:08 AM Michael Biebl wrote: > Can you reproduce this problem with systemd v226 from unstable/testing? Yes. It happens with version 226-3. > If so, it would be great if you can file this issue upstream at > https://github.com/systemd/systemd/issues OK. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
backport to Jessie
I'm trying to rebuild the latest Systemd from Unstable on Jessie to get the benefit of the latest SE Linux patches. 6c26= 1:2.24-9~), --- >libcap-dev (>= 1:2.24-8), 28c28 = 2.9.0-3+exp2) , --- >libapparmor-dev (>= 2.9.0-3) , I made the above changes to debian/control as the changelogs of the package in question didn't mention anything that seemed relevant. I backported util-linux and libseccomp from Unstable. When I tried to build systemd I got the following error: /lib64/ld-linux-x86-64.so.2 (0x562d6a528000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7fe3f3f48000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fe3f3d44000) libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x7fe3f3b3f000) libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x7fe3f38fc000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fe3f36f7000) debian/rules:164: recipe for target 'override_dh_install' failed make[1]: *** [override_dh_install] Error 1 make[1]: Leaving directory '/home/rjc/semisc/systemd/systemd-229' debian/rules:290: recipe for target 'binary' failed make: *** [binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 Any suggestions on how to rebuild it? -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: backport to Jessie
Thanks for your advice. I've disabled apparmor support and everything is fine now. On Mon, 15 Feb 2016 02:22:37 AM Martin Pitt wrote: > Hello Russell, > > Russell Coker [2016-02-13 20:55 +1100]: > > <libcap-dev (>= 1:2.24-9~), > > --- > > > > >libcap-dev (>= 1:2.24-8), > > > > 28c28 > > This is indeed only relevant for unstable/testing, as that needs > libcap2-udeb. > > > <libapparmor-dev (>= 2.9.0-3+exp2) , > > --- > > > > >libapparmor-dev (>= 2.9.0-3) , > > This is more serious -- libapparmor was moved from /usr/lib to /lib as > pid 1 now depends on it. We got reports about failed boots when having > a separate /usr and no initrd. I'd argue that this is not a supported > use case, but it's something to be aware of at least. > > (Cf. "doing the /usr merge"..) > > > When I tried to build systemd I got the following error: > > /lib64/ld-linux-x86-64.so.2 (0x562d6a528000) > > libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 > > > > (0x7fe3f3f48000) > > > > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 > > (0x7fe3f3d44000) libattr.so.1 => > > /lib/x86_64-linux-gnu/libattr.so.1 > > > > (0x7fe3f3b3f000) > > > > libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 > > > > (0x7fe3f38fc000) > > > > libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 > > > > (0x7fe3f36f7000) > > debian/rules:164: recipe for target 'override_dh_install' failed > > You cut off the interesting part, but this very much looks like the > safety check that verifies that systemd only links to libraries in > /lib, not in /usr. I suppose this is spotting the libappamor library > in /usr. > > I suggest to either backport libapparmor, or drop the build dependency > and --enable-apparmor completely for your backport. > > Martin -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#815534: systemd: should migrate config from /etc/udev/rules.d/70-persistent-net.rules
Package: systemd Version: 229-1 Severity: important To preserve the functionality of systems where the sysadmin deliberately named interfaces as well as systems where the sysadmin just configured things to work with the defaults that udev put in 70-persistent-net.rules I think that the upgrade of systemd should at least give the option of creating /etc/systemd/network/*.link files for the user. -- Package-specific info: -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.113+nmu3 ii libacl1 2.2.52-3 ii libaudit1 1:2.4.5-1 ii libblkid1 2.27.1-3.1 ii libc6 2.21-9 ii libcap2 1:2.24-12 ii libcap2-bin 1:2.24-12 ii libcryptsetup4 2:1.7.0-2 ii libgcrypt20 1.6.5-2 ii libgpg-error0 1.21-2 ii libkmod222-1 ii liblzma55.1.1alpha+20120614-2.1 ii libmount1 2.27.1-3.1 ii libpam0g1.1.8-3.2 ii libseccomp2 2.2.3-3.1 ii libselinux1 2.4-3 ii libsystemd0 229-1.1 ii mount 2.27.1-3.1 ii util-linux 2.27.1-3.1 Versions of packages systemd recommends: ii dbus1.10.6-1 ii libpam-systemd 229-1.1 Versions of packages systemd suggests: ii systemd-container 229-1.1 pn systemd-ui Versions of packages systemd is related to: ii udev 229-1.1 -- Configuration Files: /etc/systemd/journald.conf changed [not included] -- no debconf information ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#815534: systemd: should migrate config from /etc/udev/rules.d/70-persistent-net.rules
On Mon, 22 Feb 2016 07:00:01 PM Martin Pitt wrote: > > To preserve the functionality of systems where the sysadmin deliberately > > named interfaces as well as systems where the sysadmin just configured > > things to work with the defaults that udev put in > > 70-persistent-net.rules I think that the upgrade of systemd should at > > least give the option of creating /etc/systemd/network/*.link files for > > the user. > > That seems rather complicated, in some cases not possible (udev rules > can match on more attributes than *.link files), and rather error > prone IMHO. While it won't always be easy/possible I think that the vast majority of installations will match on the MAC as that is the easiest modification of rules that are automatically added. If it offered to generate link files for the easy cases that would be a significant benefit to many users. > I think it's much safer to keep the originally created > 70-persistent-net.rules on upgrades, as only this guarantees that > after the upgrade the network names are exactly the same as before the > upgrade. Currently that doesn't seem to be happening. If it had worked that way I probably wouldn't even have noticed the change. > The suggestion to remove it and update your firewall config etc. is > done because the persistent naming schema used the same namespace as > the kernel, and thus is inherently racy and broken. The mechanism > (udev rule vs. *.link file) is irrelevant there, i. e. converting to > link files would not gain anything. That is only for people who had names that match kernel names. As I don't assign names like eth0 to devices on my systems this hasn't been a problem for me. > So, my questions: What do you want achieved with that conversion? Why > is that severity "important"? I had a system stop responding to pings over the weekend. When I had it rebooted it didn't talk to the Internet. I had to visit it to discover that the ethernet device had a new name which is why rebooting it didn't bring it back from whatever problem it had. Unexpected device renames cause significant inconvenience when servers are in locations that are difficult to access. It is very important that devices which are only accessed over the Internet stay connected. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#834228: systemd: /run/utmp is created with the wrong SE Linux context
Package: systemd Version: 231-1 Severity: normal Tags: upstream The file /run/utmp is created with the wrong type on SE Linux systems. The program that creates is should either run restorecon or have internal code to set the correct context (as most of systemd does). I think it's being created by /lib/systemd/systemd-update-utmp but I'm not certain. I can provide access to a virtual machine for testing this if you wish. -- Package-specific info: -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.115 ii libacl1 2.2.52-3 ii libapparmor12.10.95-4 ii libaudit1 1:2.6.5-1 ii libblkid1 2.28-6 ii libc6 2.23-4 ii libcap2 1:2.25-1 ii libcap2-bin 1:2.25-1 ii libcryptsetup4 2:1.7.0-2 ii libgcrypt20 1.7.2-2 ii libgpg-error0 1.24-1 ii libidn111.33-1 ii libkmod222-1.1 ii liblzma55.1.1alpha+20120614-2.1 ii libmount1 2.28-6 ii libpam0g1.1.8-3.3 ii libseccomp2 2.3.1-2 ii libselinux1 2.5-3 ii libsystemd0 231-1 ii mount 2.28-6 ii util-linux 2.28-6 Versions of packages systemd recommends: ii dbus1.10.8-1 pn libpam-systemd Versions of packages systemd suggests: pn policykit-1 pn systemd-container pn systemd-ui Versions of packages systemd is related to: ii udev 231-1 -- no debconf information ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#834228: adding that line doesn't fix it
Adding the line in question makes no difference. The way you see if it worked is you run restorecon and see if it reports doing anything, if everything is OK restorecon will do nothing. Below is an example. # restorecon -v /run/utmp restorecon reset /run/utmp context system_u:object_r:var_run_t:s0- >system_u:object_r:initrc_var_run_t:s0 Would you like sysadm_r access on one of my test systems to try this out? -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#834228: more info
~/systemd-tmpfiles --create /usr/lib/tmpfiles.d/systemd.conf I copied /bin/systemd-tmpfiles to /root (so I can give it a different context). When I run the above command after logging in as root:sysadm_r it sets the correct context. But when I delete /run/utmp and run it again it doesn't recreate the file. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#834228: policy bug
reassign 834228 selinux-policy-default thanks Turns out this was a policy bug. I'll fix it soon. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#851143: systemd: doesn't use all the mount options from /etc/fstab when mounting on boot
Package: systemd Version: 232-8 Severity: normal When I boot a server that mounts a filesystem via NFS it ignores the context= mount option to set a SE Linux context of the files. What I want is to use the type mail_spool_t for a NFS mounted mail spool instead of the default nfsd_rw_t (a generic writable NFS filesystem label). Script started on Thu 12 Jan 2017 22:36:40 AEDT root@swssmtp:/tmp# ls -ldZ /mail drwxr-xr-x. 1 vmail vmail system_u:object_r:nfsd_rw_t:s0 688 Aug 15 23:54 /mail root@swssmtp:/tmp# umount /mail root@swssmtp:/tmp# mount /mail root@swssmtp:/tmp# ls -ldZ /mail drwxr-xr-x. 1 vmail vmail system_u:object_r:mail_spool_t:s0 688 Aug 15 23:54 /mail root@swssmtp:/tmp# grep mail /etc/fstab 10.10.10.1:/mailstore /mail nfs context=system_u:object_r:mail_spool_t:s0 0 0 root@swssmtp:/tmp# exit Script done on Thu 12 Jan 2017 22:37:05 AEDT -- Package-specific info: -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.115 ii libacl1 2.2.52-3 ii libapparmor12.10.95-8 ii libaudit1 1:2.6.7-1 ii libblkid1 2.29-1 ii libc6 2.24-8 ii libcap2 1:2.25-1 ii libcryptsetup4 2:1.7.3-3 ii libgcrypt20 1.7.5-2 ii libgpg-error0 1.26-1 ii libidn111.33-1 ii libip4tc0 1.6.0+snapshot20161117-4 ii libkmod223-2 ii liblz4-10.0~r131-2 ii liblzma55.2.2-1.2 ii libmount1 2.29-1 ii libpam0g1.1.8-3.4 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.6-3 ii libsystemd0 232-8 ii mount 2.29-1 ii util-linux 2.29-1 Versions of packages systemd recommends: ii dbus1.10.14-1 pn libpam-systemd Versions of packages systemd suggests: pn policykit-1 pn systemd-container pn systemd-ui Versions of packages systemd is related to: pn dracut pn initramfs-tools ii udev 232-8 -- Configuration Files: /etc/systemd/timesyncd.conf changed [not included] -- no debconf information ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#851933: Work around
If you can't fix the code before the Stretch freeze please call "restorecon /lib/udev/hwdb.bin" after running systemd-hwdb. -- Sent from my Nexus 6P with K-9 Mail. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#851933: udev: /lib/udev/hwdb.bin gets wrong SE Linux label
Package: udev Version: 232-12 Severity: normal The command "systemd-hwdb --usr update" as run from /var/lib/dpkg/info/udev.postinst creates the file /lib/udev/hwdb.bin and assigns it the SE Linux context "system_u:object_r:default_t:s0" when it should have "system_u:object_r:bin_t:s0" with the current policy. For the context of this bug report please ignore the issue of whether bin_t is the correct type of the file. I can change the type to something else if systemd-hwdb works currectly, but at the moment I have no control over the situation as systemd-hwdb is doing something I don't understand. If you can give me some pointers to debugging this program I'd be happy to debug it for you. Also I can give you administrative access to a test machine. -- Package-specific info: -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages udev depends on: ii adduser 3.115 ii dpkg 1.18.18 ii libacl1 2.2.52-3 ii libblkid12.29-1 ii libc62.24-9 ii libkmod2 23-2 ii libselinux1 2.6-3 ii libudev1 232-12 ii lsb-base 9.20161125 ii procps 2:3.3.12-3 ii util-linux 2.29-1 udev recommends no packages. udev suggests no packages. Versions of packages udev is related to: ii systemd 232-12 -- debconf information: udev/sysfs_deprecated_incompatibility: udev/title/upgrade: udev/reboot_needed: udev/new_kernel_needed: false P: /devices/LNXSYSTM:00 E: DEVPATH=/devices/LNXSYSTM:00 E: MODALIAS=acpi:LNXSYSTM: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:00 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:01 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:01 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:02 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:02 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:03 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:03 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:04 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:04 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:05 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:05 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:06 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:06 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXCPU:07 E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:07 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXPWRBN:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00 E: DRIVER=button E: MODALIAS=acpi:LNXPWRBN: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input5 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input5 E: EV=3 E: ID_FOR_SEAT=input-acpi-LNXPWRBN_00 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXPWRBN:00 E: ID_PATH_TAG=acpi-LNXPWRBN_00 E: KEY=10 0 E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw E: NAME="Power Button" E: PHYS="LNXPWRBN/button/input0" E: PRODUCT=19/0/1/0 E: PROP=0 E: SUBSYSTEM=input E: TAGS=:seat: E: USEC_INITIALIZED=11355717 P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input5/event4 N: input/event4 E: BACKSPACE=guess E: DEVNAME=/dev/input/event4 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input5/event4 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXPWRBN:00 E: ID_PATH_TAG=acpi-LNXPWRBN_00 E: LIBINPUT_DEVICE_GROUP=19/0/1/0:LNXPWRBN/button E: MAJOR=13 E: MINOR=68 E: SUBSYSTEM=input E: TAGS=:power-switch: E: USEC_INITIALIZED=11721675 E: XKBLAYOUT=us E: XKBMODEL=pc104 P: /devices/LNXSYSTM:00/LNXSYBUS:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00 E: MODALIAS=acpi:LNXSYBUS: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00 E: MODALIAS=acpi:PNP0A08:PNP0A03: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00 E: DRIVER=video E: MODALIAS=acpi:LNXVIDEO: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:00 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:01 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:01 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:02 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:02 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:03 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/device:03 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/
Bug#858335: systemd: should usr /run instead of /var/run
Package: systemd Version: 232-20 Severity: normal https://lists.fedoraproject.org/pipermail/devel/2011-March/150031.html The use of a /run tmpfs started in March 2011. I think it's time for all software to use /run directly not via the /var/run symlink. Among other things we have special code in the SE Linux policy to deal with access through both names for initial labeling and I'd like to just have 1 canonical name. # strings /usr/lib/systemd/libsystemd-shared-232.so|grep var.run.dbus kernel:path=/sys/fs/kdbus/0-system/bus;unix:path=/var/run/dbus/system_bus_socket -- Package-specific info: -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.115 ii libacl1 2.2.52-3+b1 ii libapparmor12.11.0-2 ii libaudit1 1:2.6.7-1 ii libblkid1 2.29.1-1 ii libc6 2.24-9 ii libcap2 1:2.25-1 ii libcryptsetup4 2:1.7.3-3 ii libgcrypt20 1.7.6-1 ii libgpg-error0 1.26-2 ii libidn111.33-1 ii libip4tc0 1.6.0+snapshot20161117-5 ii libkmod224-1 ii liblz4-10.0~r131-2+b1 ii liblzma55.2.2-1.2+b1 ii libmount1 2.29.1-1 ii libpam0g1.1.8-3.5 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.6-3 ii libsystemd0 232-20 ii mount 2.29.1-1 ii util-linux 2.29.1-1 Versions of packages systemd recommends: ii dbus1.10.16-1 pn libpam-systemd Versions of packages systemd suggests: pn policykit-1 pn systemd-container pn systemd-ui Versions of packages systemd is related to: pn dracut pn initramfs-tools ii udev 232-20 -- Configuration Files: /etc/systemd/timesyncd.conf changed [not included] -- no debconf information ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#858335: systemd: should usr /run instead of /var/run
On Tuesday, 21 March 2017 10:43:57 AM AEDT Felipe Sateler wrote: > > # strings /usr/lib/systemd/libsystemd-shared-232.so|grep var.run.dbus > > kernel:path=/sys/fs/kdbus/0-system/bus;unix:path=/var/run/dbus/system_bus_ > > socket > As you already know, this is the canonical address and has not been > changed by the dbus maintainers[1]. I don't think we should change > this until dbus itself has moved over. > > I'm not familiar with SELinux, but this string you have reported is > never used to create a file AFAICT. Systemd (sd-bus, actually) only > uses this to attempt connecting to the system dbus daemon. Is it still > a problem in this case? > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783321 The ways that this works is complex, determining which strings are used for which purpose is difficult. If we make such changes we need to make them globally via search and replace not try and hunt down which occurances of the strings are used for create and which are used for access. So I just did a grep in /usr/lib for matches. Also there are people reporting issues related to non-creation access of that path. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#859003: systemd-container: strange permissions on /dev/pts/ptmx
Package: systemd-container Version: 232-22 Severity: normal # grep pts /proc/mounts devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 # ls -l /dev/pts/ptmx c-. 1 root root 5, 2 Mar 20 21:51 /dev/pts/ptmx The above is from a regular Debian/unstable shell. # grep pts /proc/mounts devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0 # ls -l /dev/pts/ptmx crw-rw-rw-. 1 root root 5, 2 Mar 30 2017 /dev/pts/ptmx The above is from a shell run from a chroot managed by systemd-nspawn. I have systemd-nspawn starting the below shell script that runs sshd, so nothing in the chroot environment has any effect on mount options. Why does the virtual environment created by systemd-nspawn have different permissions for /dev/pts/ptmx than the outside environment? I am not claiming that what systemd-nspawn is doing is inherently wrong (it might be the correct thing for other distributions), but I believe that it should be consistent with the main Debian environment. It is plausible that systemd-nspawn is correct here and the rest of Debian is wrong, if so please reassign the bug appropriately. But as a security person I'm leaning towards minimum privileges being the correct choice, which means mode 0 would be correct and mode 666 (as used by systemd-nspawn) would be a bug. #!/bin/bash set -e restorecon -R /dev mkdir -p /var/run/sshd restorecon -R /var/run /usr/sbin/sshd -D -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages systemd-container depends on: ii dbus 1.10.16-1 ii libacl1 2.2.52-3+b1 ii libblkid12.29.2-1 ii libbz2-1.0 1.0.6-8.1 ii libc62.24-9 ii libcurl3-gnutls 7.52.1-3 ii libgcrypt20 1.7.6-1 ii libip4tc01.6.0+snapshot20161117-5 ii liblzma5 5.2.2-1.2+b1 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.6-3+b1 ii systemd 232-22 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages systemd-container recommends: ii btrfs-progs4.9.1-1 pn libnss-mymachines systemd-container suggests no packages. -- no debconf information ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#859003: systemd-container: strange permissions on /dev/pts/ptmx
On Thu, 30 Mar 2017 01:00:33 AM Felipe Sateler wrote: > From the kernel documentation: > > As an option instead of placing a /dev/ptmx device node at /dev/ptmx > > it is possible to place a symlink to /dev/pts/ptmx at /dev/ptmx or > > to bind mount /dev/ptx/ptmx to /dev/ptmx. If you opt for using > > the devpts filesystem in this manner devpts should be mounted with > > the ptmxmode=0666, or chmod 0666 /dev/pts/ptmx should be called. > > And indeed nspawn sets up /dev/ptmx as a symlink, while debian host > does not do that. In the host, /dev/ptmx has 0666 permissions. > > [1] https://www.kernel.org/doc/Documentation/filesystems/devpts.txt Fair point. So why does systemd-nspawn do things differently than the host in this regard? -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#851143: systemd: doesn't use all the mount options from /etc/fstab when mounting on boot
reopen 851143
thanks
> > Could you attach the output of
> > systemctl status mail.mount
> > systemctl show mail.mount
>
> Since I don't have a selinux enabled system so I could try and reproduce
> this and no further information was provided, I'm closing this bug report.
>
> Please reopen if you are available to debug this further.
Sorry for the delay in responding. I've attached those files.
# ls -ldZ /mail
drwxr-xr-x. 1 vmail vmail system_u:object_r:nfsd_rw_t:s0 754 May 10 12:41
/mail
# umount /mail ; mount /mail
# ls -ldZ /mail
drwxr-xr-x. 1 vmail vmail system_u:object_r:mail_spool_t:s0 754 May 10 12:41
/mail
--
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
Where=/mail
What=10.10.10.1:/mailstore
Options=rw,relatime,seclabel,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.10.10.24,local_lock=none,addr=10.10.10.1
Type=nfs4
TimeoutUSec=1min 30s
ControlPID=0
DirectoryMode=0755
SloppyOptions=no
LazyUnmount=no
ForceUnmount=no
Result=success
UID=4294967295
GID=4294967295
ExecMount={ path=/bin/mount ; argv[]=/bin/mount 10.10.10.1:/mailstore /mail -t
nfs -o context=system_u:object_r:mail_spool_t:s0,x-systemd.automount ;
ignore_errors=no ; start_time=[Tue 2017-05-23 00:07:53 AEST] ; stop_time=[Tue
2017-05-23 00:07:53 AEST] ; pid=740 ; code=exited ; status=0 }
Slice=system.slice
ControlGroup=/system.slice/mail.mount
MemoryCurrent=18446744073709551615
CPUUsageNSec=18446744073709551615
TasksCurrent=0
Delegate=no
CPUAccounting=no
CPUWeight=18446744073709551615
StartupCPUWeight=18446744073709551615
CPUShares=18446744073709551615
StartupCPUShares=18446744073709551615
CPUQuotaPerSecUSec=infinity
IOAccounting=no
IOWeight=18446744073709551615
StartupIOWeight=18446744073709551615
BlockIOAccounting=no
BlockIOWeight=18446744073709551615
StartupBlockIOWeight=18446744073709551615
MemoryAccounting=no
MemoryLow=0
MemoryHigh=18446744073709551615
MemoryMax=18446744073709551615
MemorySwapMax=18446744073709551615
MemoryLimit=18446744073709551615
DevicePolicy=auto
TasksAccounting=yes
TasksMax=4915
UMask=0022
LimitCPU=18446744073709551615
LimitCPUSoft=18446744073709551615
LimitFSIZE=18446744073709551615
LimitFSIZESoft=18446744073709551615
LimitDATA=18446744073709551615
LimitDATASoft=18446744073709551615
LimitSTACK=18446744073709551615
LimitSTACKSoft=8388608
LimitCORE=18446744073709551615
LimitCORESoft=0
LimitRSS=18446744073709551615
LimitRSSSoft=18446744073709551615
LimitNOFILE=4096
LimitNOFILESoft=1024
LimitAS=18446744073709551615
LimitASSoft=18446744073709551615
LimitNPROC=7977
LimitNPROCSoft=7977
LimitMEMLOCK=65536
LimitMEMLOCKSoft=65536
LimitLOCKS=18446744073709551615
LimitLOCKSSoft=18446744073709551615
LimitSIGPENDING=7977
LimitSIGPENDINGSoft=7977
LimitMSGQUEUE=819200
LimitMSGQUEUESoft=819200
LimitNICE=0
LimitNICESoft=0
LimitRTPRIO=0
LimitRTPRIOSoft=0
LimitRTTIME=18446744073709551615
LimitRTTIMESoft=18446744073709551615
OOMScoreAdjust=0
Nice=0
IOScheduling=0
CPUSchedulingPolicy=0
CPUSchedulingPriority=0
TimerSlackNSec=5
CPUSchedulingResetOnFork=no
NonBlocking=no
StandardInput=null
StandardOutput=inherit
StandardError=inherit
TTYReset=no
TTYVHangup=no
TTYVTDisallocate=no
SyslogPriority=30
SyslogLevelPrefix=yes
SyslogLevel=6
SyslogFacility=3
SecureBits=0
CapabilityBoundingSet=18446744073709551615
AmbientCapabilities=0
DynamicUser=no
RemoveIPC=no
MountFlags=0
PrivateTmp=no
PrivateDevices=no
ProtectKernelTunables=no
ProtectKernelModules=no
ProtectControlGroups=no
PrivateNetwork=no
PrivateUsers=no
ProtectHome=no
ProtectSystem=no
SameProcessGroup=yes
UtmpMode=init
IgnoreSIGPIPE=yes
NoNewPrivileges=no
SystemCallErrorNumber=0
RuntimeDirectoryMode=0755
MemoryDenyWriteExecute=no
RestrictRealtime=no
RestrictNamespace=2114060288
KillMode=control-group
KillSignal=15
SendSIGKILL=yes
SendSIGHUP=no
Id=mail.mount
Names=mail.mount
Requires=system.slice -.mount
Wants=network-online.target
Conflicts=umount.target
Before=umount.target remote-fs.target
After=remote-fs-pre.target mail.automount -.mount network-online.target
system.slice network.target
TriggeredBy=mail.automount
RequiresMountsFor=/
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Description=/mail
LoadState=loaded
ActiveState=active
SubState=mounted
FragmentPath=/run/systemd/generator/mail.mount
SourcePath=/etc/fstab
UnitFileState=generated
UnitFilePreset=enabled
StateChangeTimestamp=Tue 2017-05-23 00:07:53 AEST
StateChangeTimestampMonotonic=10421737
InactiveExitTimestamp=Tue 2017-05-23 00:07:53 AEST
InactiveExitTimestampMonotonic=10037643
ActiveEnterTimestamp=Tue 2017-05-23 00:07:53 AEST
ActiveEnterTimestampMonotonic=10401752
ActiveExitTimestampMonotonic=0
InactiveEnterTimestampMonotonic=0
CanStart=yes
CanStop=yes
CanReload=yes
CanIsolate=no
StopWhenUnneeded=no
RefuseManualStart=no
RefuseManualStop=no
AllowIsolate=no
DefaultDependencies=yes
OnFailureJobMode=replace
IgnoreOnIsolate=yes
NeedDaemonReload=no
JobTimeoutUSec=infinity
JobTimeoutAction=none
Bug#851143: systemd: doesn't use all the mount options from /etc/fstab when mounting on boot
On Tue, 23 May 2017 02:49:21 AM Michael Biebl wrote:
> > Sorry for the delay in responding. I've attached those files.
>
> The configuration you attached doesn't seem to match up.
> E.g. the original fstab didn't have x-systemd.automount.
I've set the system to not use automount, rebooted it, and run those commands
again.
> The ExecMount shows that mount has apparently been called as
> /bin/mount 10.10.10.1:/mailstore /mail -t nfs -o
> context=system_u:object_r:mail_spool_t:s0,x-systemd.automount
>
> I.e. "context=system_u:object_r:mail_spool_t:s0" has been passed along
> correctly.
>
> Are you absolutely sure it was actually systemd which has mounted
> /mailstore?
In the case of x-automount absolutely. In the case of not using automount,
how else would it be happening?
On Tue, 23 May 2017 03:05:59 AM Michael Biebl wrote:
> What happens, if you run
>
> umount /mail
> mount 10.10.10.1:/mailstore /mail -t nfs -o
> context=system_u:object_r:mail_spool_t:s0,x-systemd.automount
>
> Are the options correctly applied then?
# ls -ldZ /mail
drwxr-xr-x. 1 vmail vmail system_u:object_r:nfsd_rw_t:s0 754 May 10 12:41
/mail
# umount /mail ; mount /mail
# ls -ldZ /mail
drwxr-xr-x. 1 vmail vmail system_u:object_r:mail_spool_t:s0 754 May 10 12:41
/mail
Yes, it works fine.
I've also attached the latest version of /etc/fstab.
--
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
Where=/mail
What=10.10.10.1:/mailstore
Options=rw,relatime,seclabel,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.10.10.24,local_lock=none,addr=10.10.10.1
Type=nfs4
TimeoutUSec=1min 30s
ControlPID=0
DirectoryMode=0755
SloppyOptions=no
LazyUnmount=no
ForceUnmount=no
Result=success
UID=4294967295
GID=4294967295
ExecMount={ path=/bin/mount ; argv[]=/bin/mount 10.10.10.1:/mailstore /mail -t
nfs -o context=system_u:object_r:mail_spool_t:s0 ; ignore_errors=no ;
start_time=[Tue 2017-05-23 15:06:30 AEST] ; stop_time=[Tue 2017-05-23 15:06:30
AEST] ; pid=496 ; code=exited ; status=0 }
Slice=system.slice
ControlGroup=/system.slice/mail.mount
MemoryCurrent=18446744073709551615
CPUUsageNSec=18446744073709551615
TasksCurrent=0
Delegate=no
CPUAccounting=no
CPUWeight=18446744073709551615
StartupCPUWeight=18446744073709551615
CPUShares=18446744073709551615
StartupCPUShares=18446744073709551615
CPUQuotaPerSecUSec=infinity
IOAccounting=no
IOWeight=18446744073709551615
StartupIOWeight=18446744073709551615
BlockIOAccounting=no
BlockIOWeight=18446744073709551615
StartupBlockIOWeight=18446744073709551615
MemoryAccounting=no
MemoryLow=0
MemoryHigh=18446744073709551615
MemoryMax=18446744073709551615
MemorySwapMax=18446744073709551615
MemoryLimit=18446744073709551615
DevicePolicy=auto
TasksAccounting=yes
TasksMax=4915
UMask=0022
LimitCPU=18446744073709551615
LimitCPUSoft=18446744073709551615
LimitFSIZE=18446744073709551615
LimitFSIZESoft=18446744073709551615
LimitDATA=18446744073709551615
LimitDATASoft=18446744073709551615
LimitSTACK=18446744073709551615
LimitSTACKSoft=8388608
LimitCORE=18446744073709551615
LimitCORESoft=0
LimitRSS=18446744073709551615
LimitRSSSoft=18446744073709551615
LimitNOFILE=4096
LimitNOFILESoft=1024
LimitAS=18446744073709551615
LimitASSoft=18446744073709551615
LimitNPROC=7977
LimitNPROCSoft=7977
LimitMEMLOCK=65536
LimitMEMLOCKSoft=65536
LimitLOCKS=18446744073709551615
LimitLOCKSSoft=18446744073709551615
LimitSIGPENDING=7977
LimitSIGPENDINGSoft=7977
LimitMSGQUEUE=819200
LimitMSGQUEUESoft=819200
LimitNICE=0
LimitNICESoft=0
LimitRTPRIO=0
LimitRTPRIOSoft=0
LimitRTTIME=18446744073709551615
LimitRTTIMESoft=18446744073709551615
OOMScoreAdjust=0
Nice=0
IOScheduling=0
CPUSchedulingPolicy=0
CPUSchedulingPriority=0
TimerSlackNSec=5
CPUSchedulingResetOnFork=no
NonBlocking=no
StandardInput=null
StandardOutput=inherit
StandardError=inherit
TTYReset=no
TTYVHangup=no
TTYVTDisallocate=no
SyslogPriority=30
SyslogLevelPrefix=yes
SyslogLevel=6
SyslogFacility=3
SecureBits=0
CapabilityBoundingSet=18446744073709551615
AmbientCapabilities=0
DynamicUser=no
RemoveIPC=no
MountFlags=0
PrivateTmp=no
PrivateDevices=no
ProtectKernelTunables=no
ProtectKernelModules=no
ProtectControlGroups=no
PrivateNetwork=no
PrivateUsers=no
ProtectHome=no
ProtectSystem=no
SameProcessGroup=yes
UtmpMode=init
IgnoreSIGPIPE=yes
NoNewPrivileges=no
SystemCallErrorNumber=0
RuntimeDirectoryMode=0755
MemoryDenyWriteExecute=no
RestrictRealtime=no
RestrictNamespace=2114060288
KillMode=control-group
KillSignal=15
SendSIGKILL=yes
SendSIGHUP=no
Id=mail.mount
Names=mail.mount
Requires=-.mount system.slice
Wants=network-online.target
RequiredBy=remote-fs.target
Conflicts=umount.target
Before=remote-fs.target umount.target
After=remote-fs-pre.target -.mount network.target network-online.target
system.slice
RequiresMountsFor=/
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Description=/mail
LoadState=loaded
ActiveState=active
SubState=mounted
FragmentPath=/run/systemd/gene
Bug#887419: systemd: should depend on udev
Package: systemd Version: 232-25+deb9u1 Severity: normal On a vm at linode.com /home wouldn't be mounted (mount would hang forever with x-systemd.automount and abort leading to sulogin without it) and swap wouldn't be enabled when udev wasn't installed. udev was in "rc" state, so maybe a "dpkg --purge" would have made it work, I needed the system working so couldn't do as many tests as I might have liked. Also the serial console on /dev/ttyS0 (a virtual serial port that goes to the Linode web interface) would not be enabled without udev installed. It appears that correct operation requires udev installed. A package requirement would prevent minimal installations from breaking. -- Package-specific info: -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.12-x86_64-linode92 (SMP w/8 CPU cores) Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=UTF-8) (ignored: LC_ALL set to en_AU.UTF-8), LANGUAGE=en_AU (charmap=UTF-8) (ignored: LC_ALL set to en_AU.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.115 ii libacl1 2.2.52-3+b1 ii libapparmor12.11.0-3 ii libaudit1 1:2.6.7-2 ii libblkid1 2.29.2-1 ii libc6 2.24-11+deb9u1 ii libcap2 1:2.25-1 ii libcryptsetup4 2:1.7.3-4 ii libgcrypt20 1.7.6-2+deb9u2 ii libgpg-error0 1.26-2 ii libidn111.33-1 ii libip4tc0 1.6.0+snapshot20161117-6 ii libkmod223-2 ii liblz4-10.0~r131-2+b1 ii liblzma55.2.2-1.2+b1 ii libmount1 2.29.2-1 ii libpam0g1.1.8-3.6 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.6-3+b3 ii libsystemd0 232-25+deb9u1 ii mount 2.29.2-1 ii procps 2:3.3.12-3 ii util-linux 2.29.2-1 Versions of packages systemd recommends: ii dbus1.10.24-0+deb9u1 ii libpam-systemd 232-25+deb9u1 Versions of packages systemd suggests: ii policykit-10.105-18 pn systemd-container pn systemd-ui Versions of packages systemd is related to: pn dracut pn initramfs-tools ii udev 232-25+deb9u1 -- Configuration Files: /etc/systemd/logind.conf changed [not included] -- no debconf information ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#753790: systemd: process 1 should load new versions of shared objects
Source: systemd Version: all Severity: normal https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753726 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753727 The above bugs concern the ability of library packages to request that systemd use the new version on an upgrade. I don't think it's reasonable for the library updates to never be applied because there's the risk of a security flaw being discovered in one of them that affects the operation of systemd. As there is apparently a reliability issue in the library postinst calling "telinit u" I think that systemd should have triggers to allow it to take the new libraries when they are installed. -- Package-specific info: -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash 0 overridden configuration files found. systemctl-dump.txt Description: inode/empty ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/atd.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/auditd.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/binfmt-support.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/cups.path <== ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/fancontrol.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/lm-sensors.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/mcstrans.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/restorecond.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/rsyslog.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/ssh.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/printer.target.wants/cups.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/cups.socket <== ==> /var/lib/systemd/deb-systemd-helper-enabled/atd.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/atd.service ==> /var/lib/systemd/deb-systemd-helper-enabled/binfmt-support.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/binfmt-support.service ==> /var/lib/systemd/deb-systemd-helper-enabled/cups.path.dsh-also <== /etc/systemd/system/multi-user.target.wants/cups.path ==> /var/lib/systemd/deb-systemd-helper-enabled/cups.service.dsh-also <== /etc/systemd/system/sockets.target.wants/cups.socket /etc/systemd/system/multi-user.target.wants/cups.path /etc/systemd/system/printer.target.wants/cups.service ==> /var/lib/systemd/deb-systemd-helper-enabled/cups.socket.dsh-also <== /etc/systemd/system/sockets.target.wants/cups.socket ==> /var/lib/systemd/deb-systemd-helper-enabled/fancontrol.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/fancontrol.service ==> /var/lib/systemd/deb-systemd-helper-enabled/lm-sensors.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/lm-sensors.service ==> /var/lib/systemd/deb-systemd-helper-enabled/mcstrans.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/mcstrans.service ==> /var/lib/systemd/deb-systemd-helper-enabled/restorecond.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/restorecond.service ==> /var/lib/systemd/deb-systemd-helper-enabled/rsyslog.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/rsyslog.service /etc/systemd/system/syslog.service /etc/systemd/system/multi-user.target.wants/rsyslog.service /etc/systemd/system/syslog.service ==> /var/lib/systemd/deb-systemd-helper-enabled/ssh.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/ssh.service /etc/systemd/system/sshd.service ==> /var/lib/systemd/deb-systemd-helper-enabled/ssh.socket.dsh-also <== /etc/systemd/system/sockets.target.wants/ssh.socket ==> /var/lib/systemd/deb-systemd-helper-enabled/sshd.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/syslog.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/auditd.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/auditd.service # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # proc/proc procdefaults0 0 /dev/mapper/root-crypt / btrfsssd,noatime 0 0 #/dev/mapper/root-crypt /home btrfsssd,relatime,subvol=home 0 0 #/dev/mapper/root-crypt /junk btrfsssd,relatime,subvol=junk 0 0 #UUID=e18bcc84-a8f4-4f3a-afef-e7a9e14e6200 /boot
Bug#753790: systemd: process 1 should load new versions of shared objects
On Sat, 5 Jul 2014 04:40:33 Michael Biebl wrote: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753726 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753727 > > > > The above bugs concern the ability of library packages to request that > > systemd use the new version on an upgrade. I don't think it's reasonable > > for the library updates to never be applied because there's the risk of a > > security flaw being discovered in one of them that affects the operation > > of systemd. > While I agree with you in general, keep in mind that this is actually > also a general issue. PID 1 is in no way special in that regard and this > concerns every long running process / daemon. Pid 1 is special in that it must always exist. > It's not like a security update of libselinux (or any other library for > that matter) restarts all daemons / binaries linking against said library. I think it should. We already have pam and libc6 restarting all daemons that link against them. > Incidentally we discussed exactly that within the pkg-systemd team > before I filed this bug. Our conclusion was, that the right answer for > that is probably something like checkrestart which is run *after* the > upgrade has completed. Sounds reasonable. > > As there is apparently a reliability issue in the library postinst calling > > "telinit u" I think that systemd should have triggers to allow it to take > > the new libraries when they are installed. > > I'm not convinced that a package-individual trigger is the right answer > for this (we also discussed this possibility within the team). Every > package providing a long running system service would have to provide > such a trigger and every library would have to call all triggers. That > doesn't scale. Why not? A typical system only has a couple of dozen long running daemons and for most of them there aren't many libraries that they link against (except systemd). Of the daemons that are long running there are only a few that may cause difficulty to restart, that's systemd, xen daemons, an XDM, and rsyslogd. > We need a general solution for this. > > What I'm convinced about though is, that restarting a daemon (or > re-execing PID 1) midway through an upgrade is bound to fail one way or > another. > > So I still kindly ask you to apply the patches in #753726 and #753727 OK I think we should do that next time we update them. I don't think it's worth doing a special update for that. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ signature.asc Description: This is a digitally signed message part. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#756725: systemd: should reboot even it umount / fails
Package: systemd Version: 44-11+deb7u4 Severity: normal Today I had a server fail to restart when I ran the "reboot" command. When I got to it I saw the following on the console: Could not remount as read-only /: Device or resource busy Not all file systems unmounted, 1 left. Cannot finalize remaining file systems and devices, giving up. Then it hung, presumably indefinitely. I think it should do a forced reboot in that situation so that we have a usable system. Having it hang on a "shutdown" would usually be OK but on a reboot the sysadmin wants the system to run again. -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii dpkg 1.16.15 ii initscripts 2.88dsf-41+deb7u1 ii libacl1 2.2.51-8 ii libaudit01:1.7.18-1.1 ii libc62.19-7 ii libcap2 1:2.22-1.2 ii libcryptsetup4 2:1.4.3-4 ii libdbus-1-3 1.6.8-1+deb7u3 ii libkmod2 9-3 ii liblzma5 5.1.1alpha+20120614-2 ii libpam0g 1.1.3-7.1 ii libselinux1 2.1.9-5 ii libsystemd-daemon0 44-11+deb7u4 ii libsystemd-id128-0 44-11+deb7u4 ii libsystemd-journal0 44-11+deb7u4 ii libsystemd-login044-11+deb7u4 ii libudev0 175-7.2 ii libwrap0 7.6.q-24 ii udev 175-7.2 ii util-linux 2.20.1-5.3 Versions of packages systemd recommends: ii libpam-systemd 44-11+deb7u4 Versions of packages systemd suggests: ii python2.7.8-1 pn python-cairo pn python-dbus pn systemd-gui -- Configuration Files: /etc/systemd/systemd-journald.conf changed: [Journal] SystemMaxUse=50M ImportKernel=no -- no debconf information ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
systemd-tmpfile
Below is part of the dmesg output on a SE Linux server and ls output showing
what it matches to. Why is systemd-tmpfile trying to do a chmod type operation
on directories such as /var?
I haven't filed a bug report because I'm not sure it's a bug. I didn't post to
debian-devel because that would just give a flame war.
[ 14.376965] audit: type=1400 audit(1413115233.220:5): avc: denied {
setattr } for pid=286 comm="systemd-tmpfile" name="var" dev="sda3" ino=257
scontext=system_u:system_r:systemd_tmpfiles_t:s0
tcontext=system_u:object_r:var_t:s0 tclass=dir permissive=0
[ 14.429257] audit: type=1400 audit(1413115233.272:6): avc: denied {
setattr } for pid=286 comm="systemd-tmpfile" name="log" dev="sda3" ino=822
scontext=system_u:system_r:systemd_tmpfiles_t:s0
tcontext=system_u:object_r:var_log_t:s0 tclass=dir permissive=0
[ 14.736252] audit: type=1400 audit(1413115233.580:7): avc: denied {
setattr } for pid=286 comm="systemd-tmpfile" name="cache" dev="sda3" ino=274
scontext=system_u:system_r:systemd_tmpfiles_t:s0
tcontext=system_u:object_r:var_t:s0 tclass=dir permissive=0
[ 14.965857] audit: type=1400 audit(1413115233.808:8): avc: denied {
setattr } for pid=286 comm="systemd-tmpfile" name="lib" dev="sda3" ino=270
scontext=system_u:system_r:systemd_tmpfiles_t:s0
tcontext=system_u:object_r:var_lib_t:s0 tclass=dir permissive=0
[ 15.027358] audit: type=1400 audit(1413115233.872:9): avc: denied {
setattr } for pid=286 comm="systemd-tmpfile" name="systemd" dev="sda3"
ino=81298 scontext=system_u:system_r:systemd_tmpfiles_t:s0
tcontext=system_u:object_r:var_lib_t:s0 tclass=dir permissive=0
[ 15.090673] audit: type=1400 audit(1413115233.932:10): avc: denied {
write } for pid=286 comm="systemd-tmpfile" name="systemd" dev="sda3" ino=81298
scontext=system_u:system_r:systemd_tmpfiles_t:s0
tcontext=system_u:object_r:var_lib_t:s0 tclass=dir permissive=0
root@sexen:~# ls -lid /var
257 drwxr-xr-x. 1 root root 90 Apr 29 21:34 /var
root@sexen:~# ls -lid /var/log
822 drwxr-xr-x. 1 root root 2040 Oct 1 06:25 /var/log
root@sexen:~# ls -lid /var/cache
274 drwxr-xr-x. 1 root root 108 May 20 15:08 /var/cache
root@sexen:~# ls -lid /var/lib
270 drwxr-xr-x. 1 root root 566 Oct 12 20:49 /var/lib
--
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
