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
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
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
d
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
syst
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 (
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/
__
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 }
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
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) ,
---
>libap
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~),
> > ---
> >
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
o
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 t
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 b
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
~/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 recr
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-main
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
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.or
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 cur
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 i
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
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
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
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
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, an
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 --
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 rea
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.
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 rema
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 wou
30 matches
Mail list logo
