Re: [systemd-devel] [RFC] Initial libsystemd-asyncns commit

[David Timothy Strauss]

Just to consider what other folks are doing, I know Fedora builds
libcurl with a thread-isolated, NSS-based resolver.

On a less-related note, at Pantheon improve DNS performance on servers
by setting resolv.conf to localhost and running Unbound there. Unbound
then uses the datacenter's recursive DNS servers for things that miss
the local cache. This minimizes the time spent in blocked threads --
and waiting for lookups even with async libraries. As a bonus, you
also get DNSSec validation when possible.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item

[Jóhann B. Guðmundsson]

On 12/28/2013 01:30 PM, Lennart Poettering wrote:

On Fri, 27.12.13 23:26,m...@zarb.org  (m...@zarb.org) wrote:


>From: Michael Scherer
>
>This permit to let system administrators decide of the domain of a service.
>This can be used with templated units to have each service in a différent
>domain ( for example, a per customer database, using MLS or anything ),
>or can be used to force a non selinux enabled system (jvm, erlang, etc)
>to start in a different domain for each service.

Hmm, so far (as I understood it) the SELinux guys always wanted to make
sure that label configuration stays in the the selinux database and
nowhere else.


Right and if you add this you need to add something for the other 
security solutions as well ( apparmor etc ).


This introduces yet another place for administrators to look at while 
debugging problems so the question to ask here is.


Is adding this ability to unit files the right way to solve what's 
trying to be solved here?


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

Re: [systemd-devel] [PATCH] systemctl: improve readability on failed commands

[Zbigniew Jędrzejewski-Szmek]

On Fri, Jan 03, 2014 at 12:37:32AM +0100, Thomas H.P. Andersen wrote:
> From: Thomas Hindoe Paaboel Andersen 
> 
> Not long ago a failed command would print:
> "Failed to start something.service: ..."
> regardless of whether the command was to start/stop/restart/etc.
> 
> With e3e0314 this was improved to print the method used. E.g. for stopping:
> "Failed to StopUnit something.service: ..."
> 
> This patch matches the method to a more human readable word. E.g:
> "Failed to stop something.service: ..."
> ---
>  src/systemctl/systemctl.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
> index 67bc426..0b50813 100644
> --- a/src/systemctl/systemctl.c
> +++ b/src/systemctl/systemctl.c
> @@ -2067,12 +2067,24 @@ static int start_unit_one(
>  &reply,
>  "ss", name, mode);
>  if (r < 0) {
> +const char *command;
> +
>  if (r == -ENOENT && arg_action != ACTION_SYSTEMCTL)
>  /* There's always a fallback possible for
>   * legacy actions. */
>  return -EADDRNOTAVAIL;
>  
> -log_error("Failed to %s %s: %s", method, name, 
> bus_error_message(error, r));
> +command =
> +streq(method, "StartUnit")  ? "start" :
> +streq(method, "StopUnit")   ? "stop" :
> +streq(method, "ReloadUnit") ? "reload" :
> +streq(method, "RestartUnit")? "restart" :
> +streq(method, "TryRestartUnit") ? 
> "try-restart" :
> +streq(method, "ReloadOrRestartUnit")? 
> "reload-or-restart" :
> +streq(method, "ReloadOrTryRestartUnit") ? 
> "reload-or-try-restart" :
> +method;
Hm, we have the opposite mapping done by hand in parse_argv too...
Maybe we could coalesce those two into a single table? I think
reduce the chances of them getting out of sync.

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

[systemd-devel] systemd-logind retrying constantly when operation is denied by selinux

[Tim Cuthbertson]

I recently noticed loud and sustained disk noise, and iotop reported that
jdb2 was going full throttle on /dev/sda1 (my root partition). I ran
`journalctl -f` to see if anything obvious was wrong, and was greeted with
the following messages:

Jan 03 10:23:04 meep systemd[1]: SELinux policy denies access.
Jan 03 10:23:04 meep systemd-logind[447]: Failed to query ActiveState:
Access denied

These two messages were appearing constantly - more than 200x per second
each. I quickly ran `setenforce 0`, and everything went quiet.

I think this is due to something I did yesterday - I used `audit2allow` to
allow system-wide systemd unit files to live in a home directory[0]. This
rule added:

allow systemd_logind_t user_home_t:service start;

When I run audit2allow again now (after the errors), it wants to add:

allow systemd_logind_t user_home_t:service { status stop };

I have now changed this to:

allow systemd_logind_t user_home_t:service *;

Which seems to compile, and hopefully won't cause the problem to recur
whenever systemd performs a new operation on this service. But I thought
I'd report my observations here anyway, since it seems pretty drastic for
systemd-logind to be retrying this failed operation 200+ times a second
when the error is "access denied" (something that is unlikely to be fixed
in the next few milliseconds).

Of course, I don't know if this failure case is distinct from other errors
that *do* benefit from immediate-and-furious-retry, so I'll leave it to the
developers to determine whether something better can / should be done here.

Cheers,
 - Tim.

[0] I have a modified user@.service unit file managed in my home partition,
because I want to run `systemd --user` via a wrapper that picks up
additional user config. I symlink it under /etc/systemd/system/ rather than
keeping it in there because / is wiped on OS upgrades, but /home is a
separate partition that I keep between upgrades.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] systemctl: improve readability on failed commands

[Thomas H.P. Andersen]

From: Thomas Hindoe Paaboel Andersen 

Not long ago a failed command would print:
"Failed to start something.service: ..."
regardless of whether the command was to start/stop/restart/etc.

With e3e0314 this was improved to print the method used. E.g. for stopping:
"Failed to StopUnit something.service: ..."

This patch matches the method to a more human readable word. E.g:
"Failed to stop something.service: ..."
---
 src/systemctl/systemctl.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 67bc426..0b50813 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -2067,12 +2067,24 @@ static int start_unit_one(
 &reply,
 "ss", name, mode);
 if (r < 0) {
+const char *command;
+
 if (r == -ENOENT && arg_action != ACTION_SYSTEMCTL)
 /* There's always a fallback possible for
  * legacy actions. */
 return -EADDRNOTAVAIL;
 
-log_error("Failed to %s %s: %s", method, name, 
bus_error_message(error, r));
+command =
+streq(method, "StartUnit")  ? "start" :
+streq(method, "StopUnit")   ? "stop" :
+streq(method, "ReloadUnit") ? "reload" :
+streq(method, "RestartUnit")? "restart" :
+streq(method, "TryRestartUnit") ? 
"try-restart" :
+streq(method, "ReloadOrRestartUnit")? 
"reload-or-restart" :
+streq(method, "ReloadOrTryRestartUnit") ? 
"reload-or-try-restart" :
+method;
+
+log_error("Failed to %s %s: %s", command, name, 
bus_error_message(error, r));
 return r;
 }
 
-- 
1.8.4.2

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

Re: [systemd-devel] [RFC] Initial libsystemd-asyncns commit

[Kay Sievers]

On Thu, Jan 2, 2014 at 10:53 PM, Tom Gundersen  wrote:
> On Wed, Dec 11, 2013 at 2:41 AM, Lennart Poettering  
> wrote:

>> To follow the naming scheme of the other libs we should probably call
>> this "sd-asyncs.c", and the header file should be in src/systemd/
>> together with the other public APIs.
>
> Hm, the fact that this is async is sort of a detail, is it not? I
> mean, all our libs are async... How about sd-dns? It is slightly
> wrong, but sd-ns could mean anything...

libsystemd-dns sounds good to me.

>> Right now I am more leaning towards the thread option. But maybe that
>> changes tomorrow again. Other opinions? Kay?
>>
>> glib is embedding a copy of libasyncns currently, they opted for the
>> thread solution. Maybe we should follow suit.
>
> Doesn't seem to be any strong arguments either way... So shall we just
> go with pthreads, if that's what's used elsewhere...?

Yeah, a thread to call into the nss stuff sound like the better option
than a worker process.

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

Re: [systemd-devel] [RFC] Initial libsystemd-asyncns commit

[Tom Gundersen]

On Thu, Jan 2, 2014 at 10:53 PM, Tom Gundersen  wrote:
> On Wed, Dec 11, 2013 at 2:41 AM, Lennart Poettering
>  wrote:
>> On Wed, 11.12.13 02:13, Daniel Buch (boogiewasth...@gmail.com) wrote:
>>
>> Heya,
>>
>> Hmm, so thinking about it I have the suspicion this should probably be
>> linked into libsystemd-bus, and thus live in src/libsystemd-bus/. The
>> reason for this is cyclic deps: libsystemd-bus really should make use of
>> this to resolve host names when used in tcp mode. However, this stuff
>> really should come with integration into sd-event out of the box too
>> which is already part of libsystemd-bus (for similar reasons). So we'd
>> have asyncns both as consumer of APIs of libsystemd-bus and as
>> provider of APIs to it.
>>
>> Of course, one could argue that DNS is hardly part of bus access but
>> then again, sd-event is neither. Maybe we should just start treating
>> libsystemd-bus as that library where everything we expose ends up in,
>> except when it is really clear that it's only consumer, never provider
>> to stuff in libsystemd-bus.
>>
>>> Reindentation is done to fit systemd
>>> ---
>>>  Makefile.am   |   23 +
>>>  src/libsystemd-asyncns/asyncns.c  | 1513 
>>> +
>>>  src/libsystemd-asyncns/asyncns.h  |  163 
>>>  src/libsystemd-asyncns/test-asyncns.c |  178 
>>>  4 files changed, 1877 insertions(+)
>>>  create mode 100644 src/libsystemd-asyncns/asyncns.c
>>>  create mode 100644 src/libsystemd-asyncns/asyncns.h
>>>  create mode 100644 src/libsystemd-asyncns/test-asyncns.c
>>>
>>> diff --git a/Makefile.am b/Makefile.am
>>> index 19da6ea..a0564b5 100644
>>> --- a/Makefile.am
>>> +++ b/Makefile.am
>>> @@ -659,6 +659,29 @@ tests += test-rtnl
>>>
>>>  # 
>>> --
>>>  noinst_LTLIBRARIES += \
>>> + libsystemd-asyncns.la
>>> +
>>> +libsystemd_asyncns_la_SOURCES = \
>>> + src/libsystemd-asyncns/asyncns.c \
>>> + src/libsystemd-asyncns/asyncns.h
>>
>> To follow the naming scheme of the other libs we should probably call
>> this "sd-asyncs.c", and the header file should be in src/systemd/
>> together with the other public APIs.
>
> Hm, the fact that this is async is sort of a detail, is it not? I
> mean, all our libs are async... How about sd-dns? It is slightly
> wrong, but sd-ns could mean anything...
>
>>> +
>>> +libsystemd_asyncns_la_CFLAGS = \
>>> + -pthread
>>> +
>>> +test_asyncns_SOURCES = \
>>> + src/libsystemd-asyncns/test-asyncns.c
>>> +
>>> +test_asyncns_LDADD = \
>>> + libsystemd-asyncns.la
>>> +
>>> +test_asyncns_LDFLAGS = \
>>> + -lresolv \
>>> + -pthread
>>
>> I figure the -lresolv thing will eventually need a configure.ac check,
>> but for now I'd just leave it like this, when this breaks for people I
>> am sure they will cook up a patch quickly...
>>
>>> +#ifdef HAVE_CONFIG_H
>>> +#include 
>>> +#endif
>>
>> Unnecessary, we do this on the gcc cmdline implicitly far all our files...
>>
>>> +
>>> +/* #undef HAVE_PTHREAD */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#ifdef HAVE_SYS_PRCTL_H
>>> +#include 
>>> +#endif
>>
>> This file isn't optional for us...
>>
>>> +
>>> +#if HAVE_PTHREAD
>>> +#include 
>>> +#endif
>>> +
>>> +#include "asyncns.h"
>>> +
>>> +#ifndef MSG_NOSIGNAL
>>> +#define MSG_NOSIGNAL 0
>>> +#endif
>>
>> This is non-Linux compat and should go i figure...
>>
>>> +struct asyncns {
>>
>> probably should be called sd_asyncns now...
>>
>>> +int fds[MESSAGE_FD_MAX];
>>> +
>>> +#ifndef HAVE_PTHREAD
>>> +pid_t workers[MAX_WORKERS];
>>> +#elseso, you just suggested pthreads is the way to go. any strong reasons?
>>> +pthread_t workers[MAX_WORKERS];
>>> +#endif
>>
>> We should probably stick to one implementation here... Either with
>> process or with threads, but not chicken out anymore like I did
>> before...
>>
>> Every other day I come to different conclusions which one would be the
>> one and only mode we should support.
>>
>> The big advantage of the process option is that things are neatly
>> isolated from the parent. THe big disadvantages are that it pollutes the
>> "ps" output and might generate page faults in the parent all the time,
>> since we fork and don't exec().
>>
>> Right now I am more leaning towards the thread option. But maybe that
>> changes tomorrow again. Other opinions? Kay?
>>
>> glib is embedding a copy of libasyncns currently, they opted for the
>> thread solution. Maybe we should follow suit.
>
> Doesn't seem to be any strong arguments either way... So shall we just
> go with pthreads, if that's what's used elsewhere...?

Kay says:
> yeah, a thread. seems natural, we do not share data with the main

Re: [systemd-devel] [RFC] Initial libsystemd-asyncns commit

[Tom Gundersen]

On Wed, Dec 11, 2013 at 2:41 AM, Lennart Poettering
 wrote:
> On Wed, 11.12.13 02:13, Daniel Buch (boogiewasth...@gmail.com) wrote:
>
> Heya,
>
> Hmm, so thinking about it I have the suspicion this should probably be
> linked into libsystemd-bus, and thus live in src/libsystemd-bus/. The
> reason for this is cyclic deps: libsystemd-bus really should make use of
> this to resolve host names when used in tcp mode. However, this stuff
> really should come with integration into sd-event out of the box too
> which is already part of libsystemd-bus (for similar reasons). So we'd
> have asyncns both as consumer of APIs of libsystemd-bus and as
> provider of APIs to it.
>
> Of course, one could argue that DNS is hardly part of bus access but
> then again, sd-event is neither. Maybe we should just start treating
> libsystemd-bus as that library where everything we expose ends up in,
> except when it is really clear that it's only consumer, never provider
> to stuff in libsystemd-bus.
>
>> Reindentation is done to fit systemd
>> ---
>>  Makefile.am   |   23 +
>>  src/libsystemd-asyncns/asyncns.c  | 1513 
>> +
>>  src/libsystemd-asyncns/asyncns.h  |  163 
>>  src/libsystemd-asyncns/test-asyncns.c |  178 
>>  4 files changed, 1877 insertions(+)
>>  create mode 100644 src/libsystemd-asyncns/asyncns.c
>>  create mode 100644 src/libsystemd-asyncns/asyncns.h
>>  create mode 100644 src/libsystemd-asyncns/test-asyncns.c
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index 19da6ea..a0564b5 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -659,6 +659,29 @@ tests += test-rtnl
>>
>>  # 
>> --
>>  noinst_LTLIBRARIES += \
>> + libsystemd-asyncns.la
>> +
>> +libsystemd_asyncns_la_SOURCES = \
>> + src/libsystemd-asyncns/asyncns.c \
>> + src/libsystemd-asyncns/asyncns.h
>
> To follow the naming scheme of the other libs we should probably call
> this "sd-asyncs.c", and the header file should be in src/systemd/
> together with the other public APIs.

Hm, the fact that this is async is sort of a detail, is it not? I
mean, all our libs are async... How about sd-dns? It is slightly
wrong, but sd-ns could mean anything...

>> +
>> +libsystemd_asyncns_la_CFLAGS = \
>> + -pthread
>> +
>> +test_asyncns_SOURCES = \
>> + src/libsystemd-asyncns/test-asyncns.c
>> +
>> +test_asyncns_LDADD = \
>> + libsystemd-asyncns.la
>> +
>> +test_asyncns_LDFLAGS = \
>> + -lresolv \
>> + -pthread
>
> I figure the -lresolv thing will eventually need a configure.ac check,
> but for now I'd just leave it like this, when this breaks for people I
> am sure they will cook up a patch quickly...
>
>> +#ifdef HAVE_CONFIG_H
>> +#include 
>> +#endif
>
> Unnecessary, we do this on the gcc cmdline implicitly far all our files...
>
>> +
>> +/* #undef HAVE_PTHREAD */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#ifdef HAVE_SYS_PRCTL_H
>> +#include 
>> +#endif
>
> This file isn't optional for us...
>
>> +
>> +#if HAVE_PTHREAD
>> +#include 
>> +#endif
>> +
>> +#include "asyncns.h"
>> +
>> +#ifndef MSG_NOSIGNAL
>> +#define MSG_NOSIGNAL 0
>> +#endif
>
> This is non-Linux compat and should go i figure...
>
>> +struct asyncns {
>
> probably should be called sd_asyncns now...
>
>> +int fds[MESSAGE_FD_MAX];
>> +
>> +#ifndef HAVE_PTHREAD
>> +pid_t workers[MAX_WORKERS];
>> +#elseso, you just suggested pthreads is the way to go. any strong reasons?
>> +pthread_t workers[MAX_WORKERS];
>> +#endif
>
> We should probably stick to one implementation here... Either with
> process or with threads, but not chicken out anymore like I did
> before...
>
> Every other day I come to different conclusions which one would be the
> one and only mode we should support.
>
> The big advantage of the process option is that things are neatly
> isolated from the parent. THe big disadvantages are that it pollutes the
> "ps" output and might generate page faults in the parent all the time,
> since we fork and don't exec().
>
> Right now I am more leaning towards the thread option. But maybe that
> changes tomorrow again. Other opinions? Kay?
>
> glib is embedding a copy of libasyncns currently, they opted for the
> thread solution. Maybe we should follow suit.

Doesn't seem to be any strong arguments either way... So shall we just
go with pthreads, if that's what's used elsewhere...?

> (Actually, it might be worth checking the glib copy, and see if they
> made any changes to the sources, which we might want to steal back for us.
>
>> +#ifndef HAVE_PTHREAD
>> +
>> +static int close_allv(const int except_fds[]) {
>
> We already have this in close_many() in util.h. This func

Re: [systemd-devel] Is there any way to stop services in cgroup?

[Andrey Borzenkov]

В Чт, 02/01/2014 в 17:43 +0200, Mantas Mikulėnas пишет:
> On Thu, Jan 2, 2014 at 4:02 PM, Tony Seo  wrote:
> > Hello.
> > I wonder that systemd has a method to stop all services in specific cgroup.
> > Actually, I have looked for a method to stop all services as the same time.
> > I have searched many manual in systemd site.
> > I couldn't find any method to stop all services which I want to stop.
> 
> If you're trying to stop all instances of a service, systemd-git
> recently had wildcard support added, so `systemctl stop
> sshd@*.service` will now work.
> 
> Otherwise, use a .target and BindsTo.
> 
> 

PartOf is probably more appropriate here. But the practical problem is
that both must be specified for each unit explicitly, which simply does
not scale for future unknown services.

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

Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item

[Michael Scherer]

Le jeudi 02 janvier 2014 à 11:30 -0500, Daniel J Walsh a écrit :
> On 12/28/2013 11:47 AM, Michael Scherer wrote:
> > Le samedi 28 décembre 2013 à 14:30 +0100, Lennart Poettering a écrit :
> >> On Fri, 27.12.13 23:26, m...@zarb.org (m...@zarb.org) wrote:
> >> 
> >>> From: Michael Scherer 
> >>> 
> >>> This permit to let system administrators decide of the domain of a
> >>> service. This can be used with templated units to have each service in
> >>> a différent domain ( for example, a per customer database, using MLS or
> >>> anything ), or can be used to force a non selinux enabled system (jvm,
> >>> erlang, etc) to start in a different domain for each service.
> >> 
> >> Hmm, so far (as I understood it) the SELinux guys always wanted to make 
> >> sure that label configuration stays in the the selinux database and 
> >> nowhere else.
> > 
> > Yep, I know and they are right, we shouldn't put configuration everywhere
> > in the system. But there is a few cases where the selinux policy cannot
> > express what we want ( or at least, I do not know how to do it ).
> > 
> > First case is doing something like openshift, with 1 different domain per
> > user. Since the transitions are mostly handled in kernel space ( except for
> > specific case like sepostgresql ), it kinda restrict what we can do in term
> > of "smart" transition. In the case of openshift, this use a specific pam
> > module (pam_openshift) and specific plugins in the code, because the policy
> > is a bit too static to handle that.
> > 
> > So using templated units, we could do for example : 
> > SELinuxContext=staff_u:staff_r:%s_t:s0-s0:c0.c1023
> > 
> > or similar tricks. Or just handle things manually, with static
> > SELinuxContext ( or include, or anything ).
> > 
> > 
> > The second case is caused by a limitation of the current way of doing 
> > transition. My main motivation is to solve 
> > https://bugzilla.redhat.com/show_bug.cgi?id=969757 , because right now, we
> > cannot ask to erlang to run in a different domain unless if we write 1
> > shell wrapper per erlang application just to trigger the transition, or
> > until we make erlang selinux-aware, like postgresql is. So rather than
> > duplicate shell wrappers or adding code everywhere, I was thinking doing it
> > in systemd directly would be beneficial for everybody by reducing needed
> > changes to the only stuff that matter, having the context we want to switch
> > to.
> > 
> > I do not expect SELinuxContext to be used by upstream units, and I guess 
> > that a distribution can decide to have them being unused by policy if 
> > that's a issue.
> > 
> > It should also be noted that upstart do support a similar configuration for
> > apparmor, 
> > https://code.launchpad.net/~mdeslaur/upstart/apparmor-support/+merge/164169
> >
> > 
> And I was pondering on adding it as well to systemd, since some systemd
> > consumers are using apparmor, and because feature parity is IMHO important
> > if we want to let people use systemd on Ubuntu.
> > 
> > 
> >> I'd like Dan Walsh's opinion whether this addition fits into what the 
> >> SELinux guys want or not. Dan?
> >> 
> >> Patch looks fine though.
> > 
> 
> I like this patch, and I have seen people saying we have this capability in
> RHEL7  :^(
> 
> Currently people in a sysvinit scripts are using runcon for similar features.
>  And as someone described handling of java, mono, erlang type scripts where
> the command is not easy to differentiate.
> 
> We also allow people to do something similar with sudo.  ROLE=unconfined_r
> TYPE=unconfined_t.
> 
> I would prefer if app writers do not start hard coding SELinux contexts into
> the unit files, but allowing administrators or third parties like openshift to
> override I do not have a problem with it.
> 
> It could allow a administrator to say run this script as unconfined_t, which
> may or may not cause other problems.
> 
> We might want to allow more granularity on this then just context.Since we
> allow sudo to specify role and type and we allow runcon to specify all fields
> of SELinux.

IE, you would like to have something like SELinuxRole, SELinuxType,
SELinuxRange and SELinuxUser, each permitting to override 1 single field
of the context ?

It shouldn't be that hard to do ( a bit longer to properly test maybe ),
I am however not sure if we should keep the 2 styles of configuration
For example, in what order would the different field be applied, if I
set SELinuxuser and the context etc.

And if we use 4 configurations directives instead of 1, it also make the
request for a default SELinux context asked by David a bit harder and a
bit less elegant ( since that would mean 4 directive for the settings, 1
directive for disabling, and 4 directive for each default of the field,
unless we only offer default context ).

I will try to cook a new version of the patch with 4 splitted fields for
next week while we discuss the proposal
-- 
Michael Scherer

__

Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/28/2013 11:47 AM, Michael Scherer wrote:
> Le samedi 28 décembre 2013 à 14:30 +0100, Lennart Poettering a écrit :
>> On Fri, 27.12.13 23:26, m...@zarb.org (m...@zarb.org) wrote:
>> 
>>> From: Michael Scherer 
>>> 
>>> This permit to let system administrators decide of the domain of a
>>> service. This can be used with templated units to have each service in
>>> a différent domain ( for example, a per customer database, using MLS or
>>> anything ), or can be used to force a non selinux enabled system (jvm,
>>> erlang, etc) to start in a different domain for each service.
>> 
>> Hmm, so far (as I understood it) the SELinux guys always wanted to make 
>> sure that label configuration stays in the the selinux database and 
>> nowhere else.
> 
> Yep, I know and they are right, we shouldn't put configuration everywhere
> in the system. But there is a few cases where the selinux policy cannot
> express what we want ( or at least, I do not know how to do it ).
> 
> First case is doing something like openshift, with 1 different domain per
> user. Since the transitions are mostly handled in kernel space ( except for
> specific case like sepostgresql ), it kinda restrict what we can do in term
> of "smart" transition. In the case of openshift, this use a specific pam
> module (pam_openshift) and specific plugins in the code, because the policy
> is a bit too static to handle that.
> 
> So using templated units, we could do for example : 
> SELinuxContext=staff_u:staff_r:%s_t:s0-s0:c0.c1023
> 
> or similar tricks. Or just handle things manually, with static
> SELinuxContext ( or include, or anything ).
> 
> 
> The second case is caused by a limitation of the current way of doing 
> transition. My main motivation is to solve 
> https://bugzilla.redhat.com/show_bug.cgi?id=969757 , because right now, we
> cannot ask to erlang to run in a different domain unless if we write 1
> shell wrapper per erlang application just to trigger the transition, or
> until we make erlang selinux-aware, like postgresql is. So rather than
> duplicate shell wrappers or adding code everywhere, I was thinking doing it
> in systemd directly would be beneficial for everybody by reducing needed
> changes to the only stuff that matter, having the context we want to switch
> to.
> 
> I do not expect SELinuxContext to be used by upstream units, and I guess 
> that a distribution can decide to have them being unused by policy if 
> that's a issue.
> 
> It should also be noted that upstart do support a similar configuration for
> apparmor, 
> https://code.launchpad.net/~mdeslaur/upstart/apparmor-support/+merge/164169
>
> 
And I was pondering on adding it as well to systemd, since some systemd
> consumers are using apparmor, and because feature parity is IMHO important
> if we want to let people use systemd on Ubuntu.
> 
> 
>> I'd like Dan Walsh's opinion whether this addition fits into what the 
>> SELinux guys want or not. Dan?
>> 
>> Patch looks fine though.
> 

I like this patch, and I have seen people saying we have this capability in
RHEL7  :^(

Currently people in a sysvinit scripts are using runcon for similar features.
 And as someone described handling of java, mono, erlang type scripts where
the command is not easy to differentiate.

We also allow people to do something similar with sudo.  ROLE=unconfined_r
TYPE=unconfined_t.

I would prefer if app writers do not start hard coding SELinux contexts into
the unit files, but allowing administrators or third parties like openshift to
override I do not have a problem with it.

It could allow a administrator to say run this script as unconfined_t, which
may or may not cause other problems.

We might want to allow more granularity on this then just context.Since we
allow sudo to specify role and type and we allow runcon to specify all fields
of SELinux.

BTW Use dwa...@redhat.com for my email, not my private (Not so private) home
email.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLFlCoACgkQrlYvE4MpobMVZgCghr6UOCybitcKKqV5HKISjKDc
EhoAn36vppR/4zrjhBeyypzlWqawDxdn
=3jEw
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [Bug] minor typo on systemd wiki page

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jan 02, 2014 at 04:31:41PM +0100, Holger Schurig wrote:
> On http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
> 
> > To create and start a unit in the cgroup tree use the StartTransientUnit()
> > method on the Manager object exposed by systemd's PID 1 on the bus,
> > see the Bus API Documentation for details. This call takes for arguments.
> 
> The last "for" should be "four".
Fixed. Thanks.

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

Re: [systemd-devel] [RFT] DHCPv4 support in networkd

[Tom Gundersen]

On Thu, Jan 2, 2014 at 4:48 PM, Reindl Harald  wrote:
>
>
> Am 02.01.2014 16:41, schrieb Tom Gundersen:
>> On Thu, Jan 2, 2014 at 4:37 PM, Reindl Harald  wrote:
>>> the problems are that if someone comes back with his Apple notebook
>>> this crap starts to using the old ip-address and triggering all sorts
>>> of alarms, firewall-rules and so on
>>
>> Hm, sounds odd. This protocol is precisely meant to avoid that sort of
>> problem (by detecting whether or not you are connecting to the same
>> network). I heard that some old Apple devices used a more naive
>> protocol that would indeed just reuse the old IP... When did you last
>> experience this? Any clue about what hardware/software version it was
>> causing the problem?
>
> 2013, OSX 10.6, the first Mac Book Pro generation not supported
> by OSX > 10.6 as far as i know, one bought a few months later
> would be supported
>
> given that this machines are not that old and expensive they
> will exist longer here and there (yes i know about the securtiy
> nightmare but in that context OSX should be banned at all)

Thanks, I'll try to dig into this a bit before implementing anything
(and anyway, I expect this to be configurable if we add it).

Cheers,

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

Re: [systemd-devel] [RFT] DHCPv4 support in networkd

[Reindl Harald]

Am 02.01.2014 16:41, schrieb Tom Gundersen:
> On Thu, Jan 2, 2014 at 4:37 PM, Reindl Harald  wrote:
>> the problems are that if someone comes back with his Apple notebook
>> this crap starts to using the old ip-address and triggering all sorts
>> of alarms, firewall-rules and so on
> 
> Hm, sounds odd. This protocol is precisely meant to avoid that sort of
> problem (by detecting whether or not you are connecting to the same
> network). I heard that some old Apple devices used a more naive
> protocol that would indeed just reuse the old IP... When did you last
> experience this? Any clue about what hardware/software version it was
> causing the problem?

2013, OSX 10.6, the first Mac Book Pro generation not supported
by OSX > 10.6 as far as i know, one bought a few months later
would be supported

given that this machines are not that old and expensive they
will exist longer here and there (yes i know about the securtiy
nightmare but in that context OSX should be banned at all)



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

Re: [systemd-devel] Is there any way to stop services in cgroup?

[Mantas Mikulėnas]

On Thu, Jan 2, 2014 at 4:02 PM, Tony Seo  wrote:
> Hello.
> I wonder that systemd has a method to stop all services in specific cgroup.
> Actually, I have looked for a method to stop all services as the same time.
> I have searched many manual in systemd site.
> I couldn't find any method to stop all services which I want to stop.

If you're trying to stop all instances of a service, systemd-git
recently had wildcard support added, so `systemctl stop
sshd@*.service` will now work.

Otherwise, use a .target and BindsTo.


-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFT] DHCPv4 support in networkd

[Tom Gundersen]

On Thu, Jan 2, 2014 at 4:37 PM, Reindl Harald  wrote:
>
>
> Am 02.01.2014 16:29, schrieb Tom Gundersen:> Hei Reindl,
>>
>> On Thu, Jan 2, 2014 at 3:52 PM, Reindl Harald  wrote:
>>>
>>> Am 02.01.2014 13:55, schrieb Tom Gundersen:
 On Thu, Jan 2, 2014 at 12:56 PM, Holger Schurig  
 wrote:
> AFAIK Mac OSX does a trick here

 Yeah, and we should do the same: 
>>>
>>> because this explains why i sometimes see firewall logs in
>>> the company network where all severs are blocking private
>>> ranges as spoofed address i would be thankful not starting
>>> the same odd behavior with linux clients
>>>
>>> this is also really funny if it leads calling your ISP
>>> names because it appears that the managed router let public
>>> IP's connect to the fileserver in a non-public range until
>>> you find out that was the public home IP of a employer
>>>
>>> please don't do that - thank you!
>>
>> I'm not sure I fully understand what you are referring to. Did you
>> read the RFC? Could you explain a bit more precisely what setups
>> causes problems under that RFC?
>
> the problems are that if someone comes back with his Apple notebook
> this crap starts to using the old ip-address and triggering all sorts
> of alarms, firewall-rules and so on

Hm, sounds odd. This protocol is precisely meant to avoid that sort of
problem (by detecting whether or not you are connecting to the same
network). I heard that some old Apple devices used a more naive
protocol that would indeed just reuse the old IP... When did you last
experience this? Any clue about what hardware/software version it was
causing the problem?

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

Re: [systemd-devel] [RFT] DHCPv4 support in networkd

[Reindl Harald]

Am 02.01.2014 16:29, schrieb Tom Gundersen:> Hei Reindl,
>
> On Thu, Jan 2, 2014 at 3:52 PM, Reindl Harald  wrote:
>>
>> Am 02.01.2014 13:55, schrieb Tom Gundersen:
>>> On Thu, Jan 2, 2014 at 12:56 PM, Holger Schurig  
>>> wrote:
 AFAIK Mac OSX does a trick here
>>>
>>> Yeah, and we should do the same: 
>>
>> because this explains why i sometimes see firewall logs in
>> the company network where all severs are blocking private
>> ranges as spoofed address i would be thankful not starting
>> the same odd behavior with linux clients
>>
>> this is also really funny if it leads calling your ISP
>> names because it appears that the managed router let public
>> IP's connect to the fileserver in a non-public range until
>> you find out that was the public home IP of a employer
>>
>> please don't do that - thank you!
>
> I'm not sure I fully understand what you are referring to. Did you
> read the RFC? Could you explain a bit more precisely what setups
> causes problems under that RFC?

the problems are that if someone comes back with his Apple notebook
this crap starts to using the old ip-address and triggering all sorts
of alarms, firewall-rules and so on

at least in one case i called our ISP names because i did not imagine
that any operating system may be that stupid to use the public IP
of the users home-internet to re-connect to the fileserver and after
that failed ask our DHCP for a correct IP



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

[systemd-devel] [Bug] minor typo on systemd wiki page

[Holger Schurig]

On http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/

> To create and start a unit in the cgroup tree use the StartTransientUnit()
> method on the Manager object exposed by systemd's PID 1 on the bus,
> see the Bus API Documentation for details. This call takes for arguments.

The last "for" should be "four".
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFT] DHCPv4 support in networkd

[Tom Gundersen]

Hei Reindl,

On Thu, Jan 2, 2014 at 3:52 PM, Reindl Harald  wrote:
>
> Am 02.01.2014 13:55, schrieb Tom Gundersen:
>> On Thu, Jan 2, 2014 at 12:56 PM, Holger Schurig  
>> wrote:
>>> AFAIK Mac OSX does a trick here
>>
>> Yeah, and we should do the same: 
>
> because this explains why i sometimes see firewall logs in
> the company network where all severs are blocking private
> ranges as spoofed address i would be thankful not starting
> the same odd behavior with linux clients
>
> this is also really funny if it leads calling your ISP
> names because it appears that the managed router let public
> IP's connect to the fileserver in a non-public range until
> you find out that was the public home IP of a employer
>
> please don't do that - thank you!

I'm not sure I fully understand what you are referring to. Did you
read the RFC? Could you explain a bit more precisely what setups
causes problems under that RFC?

Cheers,

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

Re: [systemd-devel] [RFT] DHCPv4 support in networkd

[Reindl Harald]

Am 02.01.2014 13:55, schrieb Tom Gundersen:
> On Thu, Jan 2, 2014 at 12:56 PM, Holger Schurig  
> wrote:
>> AFAIK Mac OSX does a trick here
> 
> Yeah, and we should do the same: 

because this explains why i sometimes see firewall logs in
the company network where all severs are blocking private
ranges as spoofed address i would be thankful not starting
the same odd behavior with linux clients

this is also really funny if it leads calling your ISP
names because it appears that the managed router let public
IP's connect to the fileserver in a non-public range until
you find out that was the public home IP of a employer

please don't do that - thank you!



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

Re: [systemd-devel] Is there any way to stop services in cgroup?

[Jóhann B. Guðmundsson]

On 01/02/2014 02:02 PM, Tony Seo wrote:

Hello.
I wonder that systemd has a method to stop all services in specific 
cgroup.
Actually, I have looked for a method to stop all services as the same 
time.

I have searched many manual in systemd site.
I couldn't find any method to stop all services which I want to stop.
I need some advices for solving this problem.


You would create a custom target and have all services bind to that 
target then you can simply run systemctl stop my-custom.target which 
would stop a.service b.service c.service that are bound to that target 
as opposed to having to run "systemctl stop a.service b.service c.service"


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

[systemd-devel] Is there any way to stop services in cgroup?

[Tony Seo]

Hello.
I wonder that systemd has a method to stop all services in specific cgroup.
Actually, I have looked for a method to stop all services as the same time.
I have searched many manual in systemd site.
I couldn't find any method to stop all services which I want to stop.
I need some advices for solving this problem.

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

Re: [systemd-devel] [RFT] DHCPv4 support in networkd

[Tom Gundersen]

On Thu, Jan 2, 2014 at 12:56 PM, Holger Schurig  wrote:
> AFAIK Mac OSX does a trick here

Yeah, and we should do the same: .

Cheers,

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

Re: [systemd-devel] [RFT] DHCPv4 support in networkd

[Holger Schurig]

AFAIK Mac OSX does a trick here: it uses the last IP (still in the old
lease file) and immediately configures the network with that. *) Then
it does the DHCP, asking for the same IP. If the IP returned was
changed, it will re-change. But usually it's the same IP address, and
therefore on this OS DHCP doesn't take longer than static IP.

Strictly speaking the DHCP protocol is not violated that way: DHCP
itself works as expected, e.g. the DHCP packets are following the RFC.
And ip clients should copy with changed IP addresses anyway, because
DHCP can assign any IP address at renogiation time.


*) it might do an RARP to find out if the IP is available ...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFT] DHCPv4 support in networkd

[Tom Gundersen]

On Thu, Jan 2, 2014 at 3:43 AM, Kay Sievers  wrote:
> On Wed, Jan 1, 2014 at 4:41 PM, Tom Gundersen  wrote:
>> I just pushed the last couple of patches to enable DHCPv4 support in
>> networkd[0]. Testing and feedback would be greatly appreciated.
>>
>> It is still very basic, but I'm personally using it full-time on my
>> laptop (replacing NetworkManager/ConnMan), so it should be complete
>> enough to at least start testing. If you want to use it with wifi (as
>> I'm doing), just (e.g.) enable wpa_supplicant-nl80211@.service for
>> your device and configure that for your networks manually.
>
> I have a wired e1000e connection to a DSL router.
>
> I removed NetworkManager and added that:
>
>   $ cat /etc/systemd/network/wired.network
>   [Match]
>   Name=enp0s25
>
>   [Network]
>   DHCP=yes
>
>   $ journalctl -b -o short-monotonic -u systemd-networkd.service
>   [1.318123] lon systemd[1]: Started Network Service.
>   [3.073097] lon systemd-networkd[205]: Network '(null)' being
> applied to link 'enp0s25'
>   [3.301739] lon systemd-networkd[205]: Interface 'enp0s25' is up
>   [4.815708] lon systemd-networkd[205]: Interface 'enp0s25' is connected
>   [8.943769] lon systemd-networkd[205]: Received config over DHCPv4
>   [8.952326] lon systemd-networkd[205]: Addresses set for link 'enp0s25'
>   [8.952614] lon systemd-networkd[205]: Routes set for link 'enp0s25'
>   [8.952957] lon systemd-networkd[205]: Link 'enp0s25' configured
>
> Any idea why it takes 4 seconds? Do you have any numbers for your setup?

Depending on the network I'm connecting to it takes between 200 ms and
5 seconds (the numbers seem to be stable for any given network). As
far as I have been able to tell we are not doing anything wrong (i.e.,
it simply takes the dhcp server that long to send us a reply). It has
been some time since I tried with debug output from the dhcp library
though, so should re-test to verify.

> And there is a "(null)" in the log output.

Ah, that should be changed (it tries to print the Description).

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

[systemd-devel] libsystemd-bus and glib port - problem with GVariant Serialization

[Lukasz Skalski]

Hi,

I'm working on port gdbus natively onto kdbus. I've already done most 
part of this project - Hello, RequestName, ReleaseName, List*, Get*, 
NameHasOwner and others org.freedesktop.DBus methods are implemented and 
works great, what is still missing at this moment are AddMatch and 
RemoveMatch, but it shouldn't be problem and it will be done as soon as 
I solve the current problem with serialization. So...


In glib, I changed header protocol version to '2' (header already has 
field with information about length of the additional header fields 
array - everything is as described it in GVARIANT-SERIALIZATION 
document), but if I try send method call from my gio test apllication to 
second application (which uses libsystemd-bus) I get "Bad message" from 
libsystemd-bus. It is probably problem with serialization in my glib...


I did some research. I prepared two applications - first uses my glib 
with kdbus interface, second uses libsystemd-bus. Both applications 
invoke the same method call as below:


1) Application 1 (GLIB)

  result = g_dbus_connection_call_sync (connection,
"org.freedesktop.systemd.test",
"/",
"org.freedesktop.systemd.test",
"Slow",
NULL,
NULL,
G_DBUS_CALL_FLAGS_NONE,
-1,
NULL,
&error);

2) Application 2 (LIBSYSTEMD-BUS)

r = sd_bus_message_new_method_call(
bus,
"org.freedesktop.systemd.test",
"/",
"org.freedesktop.systemd.test",
"Slow",
&m);
if (r < 0) {
log_error("Failed to allocate method call: %s", 
strerror(-r));

goto finish;co je
}

sd_bus_message_unref(reply);
reply = NULL;

r = sd_bus_call(bus, m, 0, &error, &reply);


After that I added hexdump() function to libsystemd-bus and compared the 
same method invocation in glib and libsystemd-bus after serialization:


1) Application 1 (GLIB)

: 6c 01 00 02 00 00 00 00 02 00 00 00 6d 00 00 00 l...m...
0010: 01 01 6f 00 01 00 00 00 2f 00 00 00 00 00 00 00 ..o./...
0020: 03 01 73 00 04 00 00 00 53 6c 6f 77 00 00 00 00 ..s.Slow
0030: 02 01 73 00 1c 00 00 00 6f 72 67 2e 66 72 65 65 ..s.org.free
0040: 64 65 73 6b 74 6f 70 2e 73 79 73 74 65 6d 64 2e desktop.systemd.
0050: 74 65 73 74 00 00 00 00 06 01 73 00 1c 00 00 00 test..s.
0060: 6f 72 67 2e 66 72 65 65 64 65 73 6b 74 6f 70 2e org.freedesktop.
0070: 73 79 73 74 65 6d 64 2e 74 65 73 74 00 00 00 00 systemd.test

2) Application 2 (LIBSYSTEMD-BUS)

: 6c 01 00 02 00 00 00 00 01 00 00 00 73 00 00 00 l...s...
0010: 01 00 00 00 00 00 00 00 2f 00 00 6f 00 00 00 00 /..o
0020: 03 00 00 00 00 00 00 00 53 6c 6f 77 00 00 73 00 Slow..s.
0030: 02 00 00 00 00 00 00 00 6f 72 67 2e 66 72 65 65 org.free
0040: 64 65 73 6b 74 6f 70 2e 73 79 73 74 65 6d 64 2e desktop.systemd.
0050: 74 65 73 74 00 00 73 00 06 00 00 00 00 00 00 00 test..s.
0060: 6f 72 67 2e 66 72 65 65 64 65 73 6b 74 6f 70 2e org.freedesktop.
0070: 73 79 73 74 65 6d 64 2e 74 65 73 74 00 00 73 0c systemd.test..s.
0080: 1f 47 6f 00 00 00 00 00 .Go.

As you can see above, path name, interface name and others string are in 
the same place. Problem is with signature positions. Any ideas on what 
could be causing the problem?


BR,
--
Lukasz Skalski
Samsung R&D Institute Poland
Samsung Electronics
l.skal...@partner.samsung.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel