Re: [systemd-devel] Best way to run upstream systemd
On 07/19/2018 06:26 AM, Juanjo Presa wrote: I wonder which ways are to run last systemd versions? nowadays Im running Centos 7 with systemd facebook backports (https://github.com/facebookincubator/rpm-backports). But maybe you guys have another way, NixOs? Archlinux? Tyvm. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel In order to use latest systemd, you need to ensure 1) things that depend on systemd also change accordingly 2) optionally get a recent kernel so that features added to systemd based on recent improvements on kernels could also be used. In summary, you need a build system that could build latest systemd (and optionally latest kernel) and rebuild other dependencies accordingly. I'm a yocto developer, and as a playground, I'm using local kernel and systemd projects which track the latest upstream kernel and systemd. Best Regards, Chen Qi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supervisory Watchdog notification not working when using SmackProcessLabel
Hi Casey,
Thanks you for you prompt response.
On Wed, Aug 1, 2018 at 5:32 PM Casey Schaufler wrote:
>
> On 8/1/2018 3:18 AM, Martin Townsend wrote:
> > Hi,
> >
> > I have a service running with a SmackProcessLabel that uses the
> > supervisory watchdog feature, ie calls sd_notify(). The Watchdog
> > keeps resetting the service and I get the following in the journal
> >
> > Jul 27 11:36:11 kernel: audit: type=1400 audit(1532691371.270:34):
> > lsm=SMACK fn=smack_unix_may_send action=denied subject="apphealthd"
> > object="_" requested=w pid=466 comm="apphealthd"
> > path="/run/systemd/notify"
> >
> > /run/systemd/notify is a socket so I'm guessing sd_notify kicks the
> > watchdog by writing to this socket. The problem seems to be that the
> > socket is labelled with the floor label.
>
> What does "attr -S -g SMACK64 /run/systemd/notify" report?
> It should say that the attribute value is "*". If it doesn't,
> what kernel and systemd versions are you running? What is your
> base system? (Tizen, Fedora, ...)
It did report "*" for this socket file descriptor for the
security.SMACK64 attribute.
I'm running a 4.9 Kernel built using Yocto for the i.MX6UL so it's the
NXP 4.9 Kernel. Systemd is 234 which is the version included in the
Rocko release of Yocto.
>
> UDS socket access controls are done based on the processes
> involved, not the file system object. Do you have any services
> running with the floor ("_") label?
Most services run with their own label but there are system services
running with the floor label.
>
>
> > After looking through the code that sets up the notify socket I
> > quickly patched in some code to set SMACK64IPIN and IPOUT (not sure if
> > this one is required).
> >
> > @@ -728,7 +729,12 @@ static int manager_setup_notify(Manager *m) {
> >
> > m->notify_fd = fd;
> > fd = -1;
> > -
> > +r = mac_smack_apply_fd(m->notify_fd, SMACK_ATTR_IPIN, "*");
> > +if (r < 0)
> > +log_error_errno(r, "mac_smack_apply_ip_in_fd: %m");
> > +r = mac_smack_apply_fd(m->notify_fd, SMACK_ATTR_IPOUT,
> > "@");
> > +if (r < 0)
> > +log_error_errno(r, "mac_smack_apply_ip_out_fd:
> > %m");
> > log_debug("Using notification socket %s",
> > m->notify_socket);
> > }
> >
> > And the audit message has gone.
>
> Your code above is the best way to ensure your service can
> talk to everyone. You have to be sure talking to everyone is
> really what you want to do.
This applies the SMACK64_IPIN and IPOUT on the notify socket
(/run/systemd/notify) so I'm hoping it means that any
application/service can write to the notify socket, as far as I can
tell this socket is used to kick the systemd supervisory watchdog for
a specific application. If I used a specific label then I take it I
would have to use something like
r = mac_smack_apply_fd(m->notify_fd, SMACK_ATTR_IPIN, "systemd_notify");
and have a rule like:
service_label systemd_notify rwx
for every service that runs with a SMACK process label and uses the
systemd supervisory watchdog. I don't think there would be any harm
using '*' and '@' for /run/systemd/notify though to avoid this,
hopefully the systemd devs can confirm this?
>
> > Is there a better way of ensuring /run/systemd/notify can be accessed
> > by a service with a User defined SMACK label? or is this patch to
> > manager_setup_notify sufficient?
>
> You can always add access rules to allow communications.
> In this case it would be
>
> apphealthd _ w
> _ apphealthd w
>
> Generally you don't want to add rules for the floor ("_")
> label, but that's where you're seeing an issue. If you compile
> with SECURITY_SMACK_BRINGUP and use
>
> apphealthd _ wb
> _ apphealthd wb
>
> accesses permitted by these rules will be logged so that you
> can track down who you're talking to.
Yes, trying to avoid rules with floor in :) Thanks for the tip on
SECURITY_SMACK_BRINGUP though, I'm sure it will come in useful in the
future.
>
> >
> > Many Thanks in Advance,
> > Martin.
> >
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about the default value of NamePolicy=
On Wed, Aug 1, 2018 at 7:18 PM Francis Moreau wrote: > Hello, > > I have a question regarding the default value of NamePolicy= defined > in 99-default.link. > > The value is "NamePolicy=kernel database onboard slot path" > > Could someone explain me why "onbard" is preferred over "slot" which > is preferred over "path" ? > AFAIK, "onboard" and (hotplug) "slot" names are mutually exclusive, so their relative ordering isn't that important... but if the firmware marks a device as on-board *and* also provides a slot number, then it's more likely that the slot# is garbage. Both "onboard" and "slot" are preferred over "path" because they're shorter and more descriptive (as long as the firmware provides correct values). The path, being based on PCI bus addressing, doesn't say much to most people -- at best, it's just a stable identifier. (For example, my server's integrated NIC port #1 is better named "eno1", not "enp3s0f0".) -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supervisory Watchdog notification not working when using SmackProcessLabel
On 8/1/2018 3:18 AM, Martin Townsend wrote:
> Hi,
>
> I have a service running with a SmackProcessLabel that uses the
> supervisory watchdog feature, ie calls sd_notify(). The Watchdog
> keeps resetting the service and I get the following in the journal
>
> Jul 27 11:36:11 kernel: audit: type=1400 audit(1532691371.270:34):
> lsm=SMACK fn=smack_unix_may_send action=denied subject="apphealthd"
> object="_" requested=w pid=466 comm="apphealthd"
> path="/run/systemd/notify"
>
> /run/systemd/notify is a socket so I'm guessing sd_notify kicks the
> watchdog by writing to this socket. The problem seems to be that the
> socket is labelled with the floor label.
What does "attr -S -g SMACK64 /run/systemd/notify" report?
It should say that the attribute value is "*". If it doesn't,
what kernel and systemd versions are you running? What is your
base system? (Tizen, Fedora, ...)
UDS socket access controls are done based on the processes
involved, not the file system object. Do you have any services
running with the floor ("_") label?
> After looking through the code that sets up the notify socket I
> quickly patched in some code to set SMACK64IPIN and IPOUT (not sure if
> this one is required).
>
> @@ -728,7 +729,12 @@ static int manager_setup_notify(Manager *m) {
>
> m->notify_fd = fd;
> fd = -1;
> -
> +r = mac_smack_apply_fd(m->notify_fd, SMACK_ATTR_IPIN, "*");
> +if (r < 0)
> +log_error_errno(r, "mac_smack_apply_ip_in_fd: %m");
> +r = mac_smack_apply_fd(m->notify_fd, SMACK_ATTR_IPOUT, "@");
> +if (r < 0)
> +log_error_errno(r, "mac_smack_apply_ip_out_fd: %m");
> log_debug("Using notification socket %s", m->notify_socket);
> }
>
> And the audit message has gone.
Your code above is the best way to ensure your service can
talk to everyone. You have to be sure talking to everyone is
really what you want to do.
> Is there a better way of ensuring /run/systemd/notify can be accessed
> by a service with a User defined SMACK label? or is this patch to
> manager_setup_notify sufficient?
You can always add access rules to allow communications.
In this case it would be
apphealthd _ w
_ apphealthd w
Generally you don't want to add rules for the floor ("_")
label, but that's where you're seeing an issue. If you compile
with SECURITY_SMACK_BRINGUP and use
apphealthd _ wb
_ apphealthd wb
accesses permitted by these rules will be logged so that you
can track down who you're talking to.
>
> Many Thanks in Advance,
> Martin.
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Question about the default value of NamePolicy=
Hello, I have a question regarding the default value of NamePolicy= defined in 99-default.link. The value is "NamePolicy=kernel database onboard slot path" Could someone explain me why "onbard" is preferred over "slot" which is preferred over "path" ? Thanks. -- Francis ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Supervisory Watchdog notification not working when using SmackProcessLabel
Hi,
I have a service running with a SmackProcessLabel that uses the
supervisory watchdog feature, ie calls sd_notify(). The Watchdog
keeps resetting the service and I get the following in the journal
Jul 27 11:36:11 kernel: audit: type=1400 audit(1532691371.270:34):
lsm=SMACK fn=smack_unix_may_send action=denied subject="apphealthd"
object="_" requested=w pid=466 comm="apphealthd"
path="/run/systemd/notify"
/run/systemd/notify is a socket so I'm guessing sd_notify kicks the
watchdog by writing to this socket. The problem seems to be that the
socket is labelled with the floor label.
After looking through the code that sets up the notify socket I
quickly patched in some code to set SMACK64IPIN and IPOUT (not sure if
this one is required).
@@ -728,7 +729,12 @@ static int manager_setup_notify(Manager *m) {
m->notify_fd = fd;
fd = -1;
-
+r = mac_smack_apply_fd(m->notify_fd, SMACK_ATTR_IPIN, "*");
+if (r < 0)
+log_error_errno(r, "mac_smack_apply_ip_in_fd: %m");
+r = mac_smack_apply_fd(m->notify_fd, SMACK_ATTR_IPOUT, "@");
+if (r < 0)
+log_error_errno(r, "mac_smack_apply_ip_out_fd: %m");
log_debug("Using notification socket %s", m->notify_socket);
}
And the audit message has gone.
Is there a better way of ensuring /run/systemd/notify can be accessed
by a service with a User defined SMACK label? or is this patch to
manager_setup_notify sufficient?
Many Thanks in Advance,
Martin.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ubuntu 16.04 systemd: Failed to send signal
On Mi, 01.08.18 09:31, Liu, Shuang (ADITG/ESM) (s...@de.adit-jv.com) wrote: > Hi, > > Does somebody has clue on the below issue? > Ubuntu 16.04, systemd 229, D-Bus 1.10.6 > Thanks. You turned on debug logging. If you do not you won't see it. It just means that systemd tried to send a bus message to a bus connection that already terminated. That's entirely OK though, and nothing to be concerned about. Really, ignore it. If you don't want to see it, don't turn on debug logging... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
