Re: [systemd-devel] [PATCH] smack: introduce new SmackLabelExec option

[WaLyong Cho]

On 11/11/2014 04:10 AM, Lennart Poettering wrote:
> On Tue, 11.11.14 00:43, WaLyong Cho (walyong@samsung.com) wrote:
> 
>> On 11/10/2014 10:26 PM, Lennart Poettering wrote:
>>> On Fri, 07.11.14 10:03, Casey Schaufler (ca...@schaufler-ca.com) wrote:
>>>
 Calling it SmackLabel= instead of SmackLabelExec= would be fine as
 far as I'm concerned. SmackLabel= is more consistent with SELinuxContext=
 and AppArmorProfile=, as you point out.
>>>
>>> OK!
>>>
>>> WaLyong, let's name it SmackLabel= then!
>>
>> I think I had made you to bother. Excuse me, but I'm asking you again.
>> And I think introducing new config should be careful.
>>
>> Hmm, I'm still confusing. We're already using SmackLabel= as socket
>> config item. Yeah, it can possible as both exec/socket config. But each
>> purposes are different.
>> In socket config, this config is used to set SMACK64 of socket file.
>> In exec config, this config is used to set child systemd attribute when
>> User= config is given.
>> And does we have to explain each man page? Or drop from socket package
>> and move that to exec page?
> 
>> I'm not sure it make sense.
> 
> Hmm, OK, so you might actually have a point. And this is because
> .socket units may carry ExecStartPre= command lines which are execute
> before we start listening to a socket. If we'd just have SmackLabel=
> then it would not be clear whether it applies as file system label to
> the socket fds, or if it applies as process label to the ExecStartPre=
> processes.
> 
> Hmm, I guess I am fine with SmackLabelExec= then!

Hmm, I'd thouth about this again. The name SmackLabelExec= can be shown
as the value will be set to the target processes what will be executed
by child systemd. But acctually the label only be used to access the
executable file. I think just read the SMACK64 of the executable file
and set child systemd itself will reduce our naming pain. But Casey said
it way is sneaky.

How do you think?

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

Re: [systemd-devel] [systemd-commits] units/basic.target units/poweroff.target units/reboot.target

[Zbigniew Jędrzejewski-Szmek]

On Mon, Nov 10, 2014 at 10:53:46PM +0100, Lennart Poettering wrote:
> On Thu, 06.11.14 14:44, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> 
> > On Thu, Nov 06, 2014 at 02:28:12PM +0100, Lennart Poettering wrote:
> > > On Thu, 06.11.14 12:45, Patrick Häcker (pa...@web.de) wrote:
> > > 
> > > > > > However, this one appears bogus to me. Is there any such software
> > > > > > around that really does this? And if so, this really appears weird 
> > > > > > to
> > > > > > me to support. Delaying shutdown for more than 30min is just wrong.
> > > > > Isn't this what the various "download updates and reboot" gnome-y
> > > > > things are doing?
> > > > At least unattended-upgrades from Debian/Ubuntu/... can be configured 
> > > > to 
> > > > install updates on shutdown (without any special mode or something). 
> > > > And, 
> > > > yes, this can run for more than 30 minutes, which I could already 
> > > > observe in 
> > > > its default mode (installing during normal system activities), so I see 
> > > > no 
> > > > reason why this should not happen when configured to install during 
> > > > shutdown. 
> > > > The reason is, that unattended-upgrades can basically update the whole 
> > > > distribution to the next version, which naturally can take a lot of 
> > > > time.
> > > > 
> > > > It's questionable if this is a sane setup, but I can think of setups 
> > > > where 
> > > > this might be useful, e.g. having two identically configured servers 
> > > > for 
> > > > redundancy reasons where one server would be enough. Then it might make 
> > > > sense 
> > > > to update one system during shutdown while the other one takes over. 
> > > > This has 
> > > > the advantage, that normally running servers either have the old or the 
> > > > new 
> > > > state, but never some intermediate state during the update. The 
> > > > shutdown time 
> > > > does not really matter in this case and a watchdog killing the system 
> > > > wouldn't be welcome. But all in all this seems like an exotic use
> > > > case.
> > > 
> > > Is "unattended-upgrades" a package of its own? If so, I'd probably ask
> > > the packagers to include drop-ins for reboot.target to override the
> > > timeout. That way, as soon as you install it the shutdown timeouts are
> > > disabled.
> >
> > That is suboptimal. There really should be a way to this dynamically, like 
> > saying:
> > I'm a log-running job, I need more time, but everything is still fine. This
> > type of status should require periodical pings, watchdog style. Let's say 
> > that
> > the backup job run during shutdown hangs because there's no network, we want
> > to shutdown at some point anyway.
> 
> So, we always had per-unit timeouts in place, and they are opt-out
> (with the exception of Type=oneshot services where they are
> opt-in).  Hence adding a second level of opt-out timeouts doesn't
> sound particularly attractive to me.
Agreed.
 
> The reason I added the system-wide startup/shutdown timeouts was
> really to be a safety net, so that the individual per-unit timeouts
> and the opted-out exceptions don't add up beyond bounds.
I guess that this is part of the issue: it is hard to define what
"without bounds" means. A fsck, selinux relabel, package
installation and probably many other things are effectively unbounded.
And they might happen together at the same boot. So any kind of
fixed limit is unlikely to work in the general case.

[snip Yoga case]
Sure, it solves this specific problem, but it causes significant
problems in other configurations. It seems that we're trying to solve
the problem in the wrong place. Even with the current JobTimeout
configured for basic.target there's a big window of opportunity for
the system to hang before systemd-logind.service is
started. systemd-logind.service has After=nss-user-lookup.target, and
I can image things going wrong there, especially with custom
configurations. It would be nice if the guard we put in place would
cover this too.

> Now, the question is what we can do now about this:
> 
> a) we could move logind into early boot. This has multiple problems
>though: it would need to track system state as gettys on other ttys
>should only be started in multi-user mode, not in early boot. Also,
>the behaviour would probably not be ideal: i think it would be
>preferable if the system shuts down rather then suspend if we hang
>during boot.
> 
> b) specifically do something about LUKS prompt timeouts: when a very
>long timeout is hit for essential devices we could simply turn off
>the machine again. This would fix my immediate problem, but I am
>not sure I like it too much, I think other hangs should really be
>covered too...
> 
> c) we can come up with a scheme that explicitly excludes fsck, selinux
>relabel and so on from the overall-timeout. Sounds messy and
>non-obvious given that they all have individual timeouts
>anyway... Two layers of opting out of timeouts sounds suspicious?
No go

Re: [systemd-devel] 'systemctl poweroff' no longer shuts down system -- instead, reboots ?

[Zbigniew Jędrzejewski-Szmek]

On Mon, Nov 10, 2014 at 04:22:42PM -0800, grantksupp...@operamail.com wrote:
> On Mon, Nov 10, 2014, at 04:07 PM, Lennart Poettering wrote:
> > On Thu, 30.10.14 12:30, grantksupp...@operamail.com 
> > (grantksupp...@operamail.com) wrote:
> > 
> > > exec of
> > > 
> > >   systemctl poweroff
> > > 
> > > causes, as reported, a reboot/restart
> > > 
> > > but, exec of
> > > 
> > >   systemctl --force poweroff
> > > 
> > > otoh, does shut down the machine, though not gracefully
> > 
> > This got recently fixed in git. Please verify.
> 
> I'm a bit confused.  In #systemd, I'd been told that this was not relevant to 
> my specific issue, and that the problem was solely with my distro.
> 
> So, here's where I've been discussing it:
> 
> Bug 903560 - opensuse 13.1 ( + Kernel:Stable 3.17.2 + systemd 210) exec of 
> `shutdown` restarts machine instead 
> https://bugzilla.suse.com/show_bug.cgi?id=903560#c40
> 
> Is the fixed-in-git you are referencing relevant to the issue with systemd 
> discussed at opensuse?
Unlikely, since that bug was introduced after 216.

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

Re: [systemd-devel] Shutdown problems

[Nikolaus Rath]

Lennart Poettering  writes:
> On Sat, 08.11.14 11:16, Nikolaus Rath (nikol...@rath.org) wrote:
>
>> > Please boot with "systemd.log_level=debug", then make the machine hang
>> > and check what the last things in the logs say. Maybe then paste that
>> > somewhere online and post the URL for that here, so that we can have a
>> > look.
>> 
>> Here's the output (obtained by changing log level and remounting earlier
>> in the debug.sh script):
>> 
>> https://dl.dropboxusercontent.com/u/11545826/shutdown.log
>> 
>> Thanks for your help!
>
> Hmm the logs show that systemd pretty much completed its
> shutdown. After the message "Cannot finalize remaining DM devices,
> continuing." the only thing that still runs is the shutdown hooks you
> used to generate this log, plus either a jump back into your initrd
> (if your initrd supports that) or the reboot() system call. 
>
> If the latter hangs then it's a kernel bug.

reboot -f works fine - could it still be a kernel bug?

> Please check if there are any other scripts in
> /lib/systemd/system-shutdown/ that might be at fault here.

Nope, none.

> Please check if your initrd is one of those which support jumping back
> into the initrd on shutdown. For that check if /run/initramfs/shutdown
> exists during runtime and is executable.

No, /run/initramfs/shutdown does not exist.

> If so, it's probably an
> initrd problem, please file a bug against your initrd implementation.
>
> You appear to be using LVM, I wouldn't be surprised if LVM is broken
> here, but I cannot help you debugging this, please contact the LVM
> maintainers in this case.

Is there some indication that LVN is at fault? As I said in my first
email, the crucial difference seems to be if an X11 console is active or
not:

 * If I execute "systemctl reboot" while a text console is active,
   everything works fine.

 * If I execute "systemctl reboot" while the X11 console is active, the
   system hangs (I tried waiting up to 7 minutes). Furthermore, I am
   unable to switch to another console with Ctrl+Alt+Fn, the computer
   becomes unresponsive to the keyboard and the monitor powers down.

On which tty/pty systemctl itself is executed does not matter (I tested
this by running systemctl in an ssh session from a remote system), it
only matters which console is currently active.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] 'systemctl poweroff' no longer shuts down system -- instead, reboots ?

[grantksupport]

On Mon, Nov 10, 2014, at 04:07 PM, Lennart Poettering wrote:
> On Thu, 30.10.14 12:30, grantksupp...@operamail.com 
> (grantksupp...@operamail.com) wrote:
> 
> > exec of
> > 
> >   systemctl poweroff
> > 
> > causes, as reported, a reboot/restart
> > 
> > but, exec of
> > 
> >   systemctl --force poweroff
> > 
> > otoh, does shut down the machine, though not gracefully
> 
> This got recently fixed in git. Please verify.

I'm a bit confused.  In #systemd, I'd been told that this was not relevant to 
my specific issue, and that the problem was solely with my distro.

So, here's where I've been discussing it:

Bug 903560 - opensuse 13.1 ( + Kernel:Stable 3.17.2 + systemd 210) exec of 
`shutdown` restarts machine instead 
https://bugzilla.suse.com/show_bug.cgi?id=903560#c40

Is the fixed-in-git you are referencing relevant to the issue with systemd 
discussed at opensuse?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Add timesync-wait tool

[Lennart Poettering]

On Wed, 29.10.14 17:50, Lukasz Stelmach (stl...@poczta.fm) wrote:

> > I mean, what is the tool supposed to be
> > waiting on: that the time is set as accurately as possible (in that
> > case watching STA_UNSYNC sounds good, plus waiting for
> > TFD_CANCEL_ON_SET for big jumps and guessing sleep times from
> > adjtimex()'s return values for smaller jumps)?
> 
> There is no point in "guessing". Clearing STA_UNSYNC takes one
> timesynced cycle (32s, see below).

Well, the algorithm I was envisioning there would be one which
wouldn#t strictly be tied to timesycnd being the NTP server. By
checking what adjtimex returns I figure we could guess when the fix is
likely to be done.

> > Or that the time is set
> > accurately enough for adjtimex() to be used for the remaining accuracy
> > (In that case, we'd actually have to make timesyncd report this
> > information to us, maybe using a flag file to watch via inotify)?
> 
> This is probably what satisfies most users.
>
> > Or
> > that the time set accurately enough to be monotonic, but not more (in
> > that case just ordering after systemd-timesyncd.service should be
> > enough, no need for any other tool)?
> 
> timesyncd sends READY=1 quite early. I think it is before it tries to
> contact time servers.

Yes. And that's really the right thing to do. In normal setups we
really should not wait for external conditions.

> > Of these three options, I think the first one is not necessarily a
> > good idea, since adjtimex() is really about making time corrections
> > smooth and hence slow. Making this slow, and trying to wait for it is
> > kinda contradictory, no?
> 
> Not really, that is it isn't that slow. I measured it. First I set the
> current time off by less than a minute then waited
> 
> date $(date +%m%d%H%M%Y) && sleep 2 && time ./systemd-timesync-wait
> 
> and it always took one timesyncd cycle (32 seconds) to clear STA_UNSYNC.
> 
> How about waiting for either a flag-file which timesyncd creates after
> a few seconds timesynced is started or, if a user chooses so, for the
> "real" synchronisation?
> 
> > The third one is not a good idea either, since we already have
> > functionality covering that.
> > 
> > But if the second option is the relevant one, then I figure neither
> > adjtimex() nor TFP_CANCEL_ON_SET will be useful to us, and instead we
> > need to teach systemd-timesyncd some flag file stuff.
> 
> Yes, like "hey I've already received the time from an NTP server and fed
> it to the kernel".
> 
> Create /run/systemd/timesyncd/synchronised here:
> 
> http://cgit.freedesktop.org/systemd/systemd/tree/src/timesync/timesyncd-manager.c?id=v217#n389

Correct.

> and unlink it here
> 
> http://cgit.freedesktop.org/systemd/systemd/tree/src/timesync/timesyncd-manager.c?id=v217#n293

Sure? (see below)

> and of upon exit. An erroneous one too.

Hmm, why remove it on exit or on time change? I mean, I figure this
really should be a one-time thing: a way how the tool can wait until
the first sync is acquired, and that's it.

> 
> >>> The same way as network-wait-online has a timeout this tool should
> >>> probably have one too.
> >>
> >> If the timeout is reached the tool exits with a non-zero code. Right?
> >> That makes sense. Is three minutes OK?
> > 
> > I'd use the same default timeout as for systemd-network-wait-online,
> > for whatever that is.
> 
> Are you sure there is a timeout? The service type is oneshot (timeout is
> disabled according to systemd.service(5)) without any Timeout* set. Two
> calls to sd_event_exit() in the code depend manager_all_configured() and
> no sign of any timer.

Indeed. It really should have one though. Added to TODO list now.


Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Commands started after "su - username" do not obey "systemctl set-property user.slice MemoryLimit=..."

[Lennart Poettering]

On Wed, 29.10.14 21:08, Lutz Vieweg (l...@5t9.de) wrote:

> Hi,
> 
> I configured a CentOS 7 to limit the amount of memory any single
> interactive user can use by setting:
> 
> >systemctl set-property user.slice MemoryLimit=60G
> 
> and excepted "root" to use a less strict limit:
> 
> >systemctl set-property user-0.slice MemoryLimit=120G
> 
> Works so far, but there's a catch: Some times, "root"
> wants to impersonate some user to interactively start
> some software on behalf of that user.
> 
> Yet, when root uses "su - username" to change the user,
> no "user-xxx.slice" is created, not even a new "session"
> below "user-0.slice" is created, causing the wrong
> MemoryLimit to be applied:
> 
> >systemd-cgls
> >└─user.slice
> >  ├─user-0.slice
> >...
> >  │ └─session-18.scope
> >  │   ├─17570 sshd: root@pts/1
> >  │   ├─17572 -bash
> >  │   ├─19514 bash
> >  │   ├─19884 su - johndoe
> >  │   ├─19885 -bash
> >  │   ├─20395 ./memory_hog ...
> 
> How can I configure that processes started as a certain
> user honor the user.slice limit, regardless of whether
> the user used "ssh" to log in, or whether just "root"
> was using "su" to become that user?

Using "su" doesn't really open a new session, it really just changes
the numeric UID, and very few other things. It does not create a new
bus, doesn't pass access to the audio stack, does not create a new
tty, no new XDG_RUNTIME_DIR or anything else. It's a mix and match you
get between the old user and the new user, and part of that is that no
new session is registered by logind, and hence no resources are
applied.

By using "su" you basically tell the system that you want to quickly
and temporarily change your uid, but *without* doing a full new login,
hence staying within your old session. Hence this is what you get...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] 'systemctl poweroff' no longer shuts down system -- instead, reboots ?

[Lennart Poettering]

On Thu, 30.10.14 12:30, grantksupp...@operamail.com 
(grantksupp...@operamail.com) wrote:

> exec of
> 
>   systemctl poweroff
> 
> causes, as reported, a reboot/restart
> 
> but, exec of
> 
>   systemctl --force poweroff
> 
> otoh, does shut down the machine, though not gracefully

This got recently fixed in git. Please verify.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 5/5] calendar: parse months's names

[Lennart Poettering]

On Thu, 30.10.14 12:19, Daniele Medri (dme...@gmail.com) wrote:

As mentiond in my early review, such a bitfield would duplicate the
"months" chain we already have in place.

I am totally onboard with allowing a syntax where month names are
used, but this really should be translated into the normal chain stuff
internally, to avoid a redundant structure in memory!

Lennart

> ---
>  man/systemd.time.xml  |   9 +++
>  src/shared/calendarspec.c | 202 
> ++
>  src/shared/calendarspec.h |   1 +
>  3 files changed, 212 insertions(+)
> 
> diff --git a/man/systemd.time.xml b/man/systemd.time.xml
> index 2ee5858..d108871 100644
> --- a/man/systemd.time.xml
> +++ b/man/systemd.time.xml
> @@ -225,6 +225,15 @@
>  range of continuous weekdays. , and
>  - may be combined freely.
>  
> +The months's names specification is available too.
> +It should consist of one or more English
> +language months's names, either in the abbreviated
> +(Apr) or non-abbreviated (April) form (case does
> +not matter), separated by commas. Specifying two
> +months separated by - refers to a
> +range of continuous months. , and
> +- may be combined freely.
> +
>  In the date and time specifications, any
>  component may be specified as * in
>  which case any value will match. Alternatively, each
> diff --git a/src/shared/calendarspec.c b/src/shared/calendarspec.c
> index 9b05f13..dea83ce 100644
> --- a/src/shared/calendarspec.c
> +++ b/src/shared/calendarspec.c
> @@ -25,6 +25,7 @@
>  #include "calendarspec.h"
>  
>  #define BITS_WEEKDAYS127
> +#define BITS_MONTHS  4095/* 0^2 + 1^2 + ... + 11^2 */
>  
>  static void free_chain(CalendarComponent *c) {
>  CalendarComponent *n;
> @@ -125,6 +126,9 @@ int calendar_spec_normalize(CalendarSpec *c) {
>  if (c->weekdays_bits <= 0 || c->weekdays_bits >= BITS_WEEKDAYS)
>  c->weekdays_bits = -1;
>  
> +if (c->months_bits <= 0 || c->months_bits >= BITS_MONTHS)
> +c->months_bits = -1;
> +
>  fix_year(c->year);
>  
>  sort_chain(&c->year);
> @@ -159,6 +163,9 @@ _pure_ bool calendar_spec_valid(CalendarSpec *c) {
>  if (c->weekdays_bits > BITS_WEEKDAYS)
>  return false;
>  
> +if (c->months_bits > BITS_MONTHS)
> +return false;
> +
>  if (!chain_valid(c->year, 1970, 2199))
>  return false;
>  
> @@ -229,6 +236,60 @@ static void format_weekdays(FILE *f, const CalendarSpec 
> *c) {
>  }
>  }
>  
> +static void format_months(FILE *f, const CalendarSpec *c) {
> +static const char *const months[] = {
> +"Jan",
> +"Feb",
> +"Mar",
> +"Apr",
> +"May",
> +"Jun",
> +"Jul",
> +"Aug",
> +"Sep",
> +"Oct",
> +"Nov",
> +"Dec"
> +};
> +
> +int l, x;
> +bool need_colon = false;
> +
> +assert(f);
> +assert(c);
> +assert(c->months_bits > 0 && c->months_bits <= BITS_MONTHS);
> +
> +for (x = 0, l = -1; x < (int) ELEMENTSOF(months); x++) {
> +
> +if (c->months_bits & (1 << x)) {
> +
> +if (l < 0) {
> +if (need_colon)
> +fputc(',', f);
> +else
> +need_colon = true;
> +
> +fputs(months[x], f);
> +l = x;
> +}
> +
> +} else if (l >= 0) {
> +
> +if (x > l + 1) {
> +fputc(x > l + 2 ? '-' : ',', f);
> +fputs(months[x-1], f);
> +}
> +
> +l = -1;
> +}
> +}
> +
> +if (l >= 0 && x > l + 1) {
> +fputc(x > l + 2 ? '-' : ',', f);
> +fputs(months[x-1], f);
> +}
> +}
> +
>  static void format_chain(FILE *f, int space, const CalendarComponent *c) {
>  assert(f);
>  
> @@ -266,6 +327,11 @@ int calendar_spec_to_string(const CalendarSpec *c, char 
> **p) {
>  fputc(' ', f);
>  }
>  
> +if (c->months_bits > 0 && c->months_bits <= BITS_MONTHS) {
> +format_months(f, c);
> +fputc(' ', f);
> +}
> +
>  format_chain(f, 4, c->year);
>  fputc('-', f);
>  format_chain(f, 2, c->month);
> @@ -385,6 +451,108 @@ static int parse_weekdays(const char **p, CalendarSpec 
> *c) {
>  }
>  }
>  
> +static int pa

Re: [systemd-devel] [PATCH 2/5] man: reorganization of calendar specs

[Lennart Poettering]

On Thu, 30.10.14 12:19, Daniele Medri (dme...@gmail.com) wrote:

> ---
>  man/systemd.time.xml | 31 ++-
>  1 file changed, 14 insertions(+), 17 deletions(-)
> 
> diff --git a/man/systemd.time.xml b/man/systemd.time.xml
> index 2342684..2ee5858 100644
> --- a/man/systemd.time.xml
> +++ b/man/systemd.time.xml
> @@ -241,23 +241,20 @@
>  
>  Timezone names may not be specified.
>  
> -The special expressions
> -minutely,
> -hourly, daily,
> -monthly, weekly,
> -yearly,
> -quarterly,
> - semesterly or semiannually
> - may be used as calendar events which refer to
> -*-*-* *:*:00,
> -*-*-* *:00:00,
> -*-*-* 00:00:00,
> -*-*-01 00:00:00,
> -Mon *-*-* 00:00:00,
> -*-01-01 00:00:00,
> -*-01,04,07,10-01 00:00:0 and
> -*-01,07-01 00:00:00 respectively.
> -
> +Special expressions may be used as calendar 
> events:
> +
> + 
> +  minutely → *-*-* *:*:00
> +hourly → *-*-* *:00:00
> + daily → *-*-* 00:00:00
> +weekly → Mon *-*-* 00:00:00
> +   monthly → *-*-01 00:00:00
> + quarterly → *-01,04,07,10-01 00:00:00
> +semesterly → *-01,07-01 00:00:00
> +  semiannually → *-01,07-01 00:00:00
> +yearly → *-01-01 00:00:00
> +  annually → *-01-01 00:00:00
> +

I'd think turning this into a proper docbook table would make a ton of
sense! Would love to take a patch for that!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 1/5] calendar: semesterly alias for semi-annually

[Lennart Poettering]

On Thu, 30.10.14 12:19, Daniele Medri (dme...@gmail.com) wrote:

I am still not convinced that "semesterly" is really a good
addition. See previous comments about that:

  I am a bit conservative about that. "Semester" has a very
  academic touch to it, and at least in germany the semester
  usually starts in october, not in january. I'd rather stay
  away from this word hence, since at least to me it appears
  to suggest something different than "*-1,7-1"...

And we do have semi-annually already that covers this nicely.

> ---
>  man/systemd.time.xml | 4 ++--
>  src/shared/calendarspec.c| 3 ++-
>  src/test/test-calendarspec.c | 1 +
>  3 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/man/systemd.time.xml b/man/systemd.time.xml
> index f35ccd7..2342684 100644
> --- a/man/systemd.time.xml
> +++ b/man/systemd.time.xml
> @@ -247,8 +247,8 @@
>  monthly, weekly,
>  yearly,
>  quarterly,
> -semiannually may be used as
> -calendar events which refer to
> + semesterly or semiannually
> + may be used as calendar events which refer to
>  *-*-* *:*:00,
>  *-*-* *:00:00,
>  *-*-* 00:00:00,
> diff --git a/src/shared/calendarspec.c b/src/shared/calendarspec.c
> index 7efcf7b..3115bba 100644
> --- a/src/shared/calendarspec.c
> +++ b/src/shared/calendarspec.c
> @@ -757,7 +757,8 @@ int calendar_spec_from_string(const char *p, CalendarSpec 
> **spec) {
>  } else if (strcaseeq(p, "biannually") ||
> strcaseeq(p, "bi-annually") ||
> strcaseeq(p, "semiannually") ||
> -   strcaseeq(p, "semi-annually")) {
> +   strcaseeq(p, "semi-annually") ||
> +   strcaseeq(p, "semesterly")) {
>  
>  r = const_chain(1, &c->month);
>  if (r < 0)
> diff --git a/src/test/test-calendarspec.c b/src/test/test-calendarspec.c
> index 87e1da1..7610cff 100644
> --- a/src/test/test-calendarspec.c
> +++ b/src/test/test-calendarspec.c
> @@ -80,6 +80,7 @@ int main(int argc, char* argv[]) {
>  test_one("minutely", "*-*-* *:*:00");
>  test_one("quarterly", "*-01,04,07,10-01 00:00:00");
>  test_one("semi-annually", "*-01,07-01 00:00:00");
> +test_one("semesterly", "*-01,07-01 00:00:00");
>  test_one("annually", "*-01-01 00:00:00");
>  test_one("*:2/3", "*-*-* *:02/3:00");
>  
> -- 
> 1.9.3
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] localed: validate set-x11-keymap input

[Lennart Poettering]

On Tue, 04.11.14 12:05, Jan Synacek (jsyna...@redhat.com) wrote:

One more addition:

> +}
> +
> +int xkb_get_keymaps(char ***list, enum keymap_state look_for, const char 
> *layout_prefix)
> +{
> +_cleanup_fclose_ FILE *f;
> +char line[LINE_MAX];
> +enum keymap_state state = NONE;
> +int r;
> +
> +f = fopen("/usr/share/X11/xkb/rules/base.lst", "re");
> +if (!f) {
> +log_error("Failed to open keyboard mapping list. %m");
> +return -errno;
> +}
> +
> +FOREACH_LINE(line, f, break) {
> +char *l, *w;
> +
> +l = strstrip(line);
> +
> +if (isempty(l))
> +continue;
> +
> +if (l[0] == '!') {
> +if (startswith(l, "! model"))
> +state = MODELS;
> +else if (startswith(l, "! layout"))
> +state = LAYOUTS;
> +else if (startswith(l, "! variant"))
> +state = VARIANTS;
> +else if (startswith(l, "! option"))
> +state = OPTIONS;
> +else
> +state = NONE;
> +
> +continue;
> +}
> +
> +if (state != look_for)
> +continue;
> +
> +w = l + strcspn(l, WHITESPACE);
> +
> +if (layout_prefix) {
> +char *e;
> +
> +if (*w == 0)
> +continue;
> +
> +*w = 0;
> +w++;
> +w += strspn(w, WHITESPACE);
> +
> +e = strchr(w, ':');
> +if (!e)
> +continue;
> +
> +*e = 0;
> +
> +if (!streq(w, layout_prefix))
> +continue;
> +} else
> +*w = 0;
> +
> +r = strv_extend(list, l);
> +if (r < 0)
> +return log_oom();


I think, while we are at it, this should really be reworked to use
GREEDY_REALLOC. See strv_split_quoted() for an example.


> +}
> +
> +if (strv_isempty(*list)) {
> +log_error("Couldn't find any entries."); /* TODO: improve 
> error message */
> +return -ENOENT;
> +}
> +
> +return 0;


Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] localed: validate set-x11-keymap input

[Lennart Poettering]

On Tue, 04.11.14 12:05, Jan Synacek (jsyna...@redhat.com) wrote:

> diff --git a/src/locale/localectl.c b/src/locale/localectl.c
> index d4a2d29..8f9e4da 100644
> --- a/src/locale/localectl.c
> +++ b/src/locale/localectl.c
> @@ -46,6 +46,7 @@
>  #include "virt.h"
>  #include "fileio.h"
>  #include "locale-util.h"
> +#include "xkb-util.h"
>  
>  static bool arg_no_pager = false;
>  static bool arg_ask_password = true;
> @@ -389,14 +390,7 @@ static int set_x11_keymap(sd_bus *bus, char **args, 
> unsigned n) {
>  static int list_x11_keymaps(sd_bus *bus, char **args, unsigned n) {
>  _cleanup_fclose_ FILE *f = NULL;
>  _cleanup_strv_free_ char **list = NULL;
> -char line[LINE_MAX];
> -enum {
> -NONE,
> -MODELS,
> -LAYOUTS,
> -VARIANTS,
> -OPTIONS
> -} state = NONE, look_for;
> +enum keymap_state look_for;

While we don#t follow this rule too strictly we usually define typdefs
for enums and name them in CamelCase. Hence, please rename this type
"KeymapState" instead of "enum keymap_state".

That said, is "state" really the right name here? Shouldn't it be
"field" or "component" or "item" or so?

>  !streq_ptr(variant, c->x11_variant) ||
>  !streq_ptr(options, c->x11_options)) {
> +_cleanup_free_ char *msg = NULL;
>  
>  if ((layout && !string_is_safe(layout)) ||
>  (model && !string_is_safe(model)) ||
> @@ -1050,6 +1052,12 @@ static int method_set_x11_keyboard(sd_bus *bus, 
> sd_bus_message *m, void *userdat
>  free_and_strdup(&c->x11_options, options) < 0)
>  return -ENOMEM;
>  
> +r = xkb_validate_keymaps(model, layout, variant, options, 
> &msg);
> +if (r < 0) {
> +log_error("Failed to validate X11 keyboard layout: 
> %s", strerror(-r));
> +return sd_bus_error_set(error, SD_BUS_ERROR_FAILED, 
> msg);
> +}
> +

Please return the error back to the client instead of logging it
away. Use sd_bus_error_setf() for that.

Use SD_BUS_ERROR_INVALID_ARGS as error id.

> +
> +static char **xkb_parse_argument(const char *arg)
> +{
> +_cleanup_free_ char *input;
> +char *token;
> +char **result = NULL;
> +int r;
> +
> +assert(arg);
> +
> +input = strdup(arg);
> +if (!input)
> +return NULL;
> +
> +token = strsep(&input, ",");
> +while(token) {
> +r = strv_extend(&result, token);
> +if (r < 0)
> +return NULL;
> +token = strsep(&input, ",");
> +}
> +
> +return result;
> +}

Please place the opening { of a function body on the same line as the
function declaration.

I figure strv_split() does exactly the same thing, please use that.

> +
> +int xkb_get_keymaps(char ***list, enum keymap_state look_for, const char 
> *layout_prefix)
> +{
> +_cleanup_fclose_ FILE *f;
> +char line[LINE_MAX];
> +enum keymap_state state = NONE;
> +int r;
> +
> +f = fopen("/usr/share/X11/xkb/rules/base.lst", "re");
> +if (!f) {
> +log_error("Failed to open keyboard mapping list. %m");
> +return -errno;
> +}

This should probably become a function call that returns errors but
doesn't log about them, leaving that to the caller.

> +int xkb_validate_keymaps(const char *model,
> + const char *layouts_arg,
> + const char *variants_arg,
> + const char *options_arg,
> + char **error)
> +{
> +int r;
> +
> +if (layouts_arg) {
> +_cleanup_strv_free_ char **layouts_list = NULL;
> +char **it, **layouts;
> +int i = 0;
> +
> +r = xkb_get_keymaps(&layouts_list, LAYOUTS, NULL);
> +if (r < 0)
> +return r;
> +
> +layouts = strv_split(layouts_arg, ",");
> +if (!layouts)
> +return log_oom();
> +
> +STRV_FOREACH(it, layouts) {
> +_cleanup_strv_free_ char **variants_list = NULL;
> +bool variants_left = true;
> +int n;
> +
> +if (!strv_find(layouts_list, *it)) {
> +r = asprintf(error, "Requested layout '%s' 
> not available.\n", *it);
> +if (r < 0)
> +return log_oom();
> +return -EINVAL;
> +}
> +
> +if (variants_left && variants_arg) {
> +_cleanup_strv_free_ char **variants;
> +
> + 

Re: [systemd-devel] [PATCHv6] tmpfiles, man: Add xattr support to tmpfiles

[Lennart Poettering]

On Thu, 30.10.14 12:21, Maciej Wereski (m.were...@partner.samsung.com) wrote:

>  
> +static int get_xattrs_from_arg(Item *i) {
> +_cleanup_free_ char *xattr = NULL;
> +const char *p;
> +int n;
> +
> +assert(i);
> +if (i->type != SET_XATTR)
> +return 0;
> +
> +if (!i->argument) {
> +log_error("%s: Argument can't be empty!", i->path);
> +return -EBADMSG;
> +}
> +p = i->argument;
> +
> +while ((n = unquote_first_word(&p, &xattr)) > 0) {
> +if (strv_extend(&i->xattrs, xattr) < 0)
> +return log_oom();
> +free(xattr);
> +xattr = NULL;
> +}

Please use strv_consume() or strv_push() here, to make the additional
copy unnecessary. Also please, generate a parse failure if
unquote_first_workd() fails due to parse errors.

> +r = get_xattrs_from_arg(i);
> +if (r < 0)
> +return r;
> +
> +if (strv_isempty(i->xattrs))
> +return 0;
> +
> +STRV_FOREACH(x, i->xattrs) {
> +_cleanup_free_ char *name = NULL, *value = NULL, *tmp = NULL;
> +n = split_pair(*x, "=", &name, &value);
> +if (n < 0)
> +return n;
> +tmp = unquote(value, "\"");
> +if (!tmp)
> +return log_oom();
> +free(value);
> +value = cunescape(tmp);
> +if (!value)
> +return log_oom();
> +n = strlen(value);
> +if (i->type == CREATE_SYMLINK) {
> +if (lsetxattr(path, name, value, n+1, 0) < 0) {
> +log_error("Setting extended attribute %s=%s 
> on symlink %s failed: %m", name, value, path);
> +return -errno;
> +}
> +}
> +else if (setxattr(path, name, value, n+1, 0) < 0) {
> +log_error("Setting extended attribute %s=%s on %s 
> failed: %m", name, value, path);
> +return -errno;
> +}

The indentation is wrong.

Should the extended attribute value really include the trailing NUL
byte? I doubt it...

Shouldn't we always invoke lsetxattr() instead of setxattr()?

If we really should keep both around, I think a single error handling
for both if blocks would be better.

>  
> @@ -894,6 +983,12 @@ static int create_item(Item *i) {
>  r = glob_item(i, item_set_perms);
>  if (r < 0)
>  return r;
> +
> +if (i->xattrs) {
> +r = glob_item(i, item_set_xattrs);
> +if (r < 0)
> +return r;
> +}
>  break;

Hmm, ths would mean we resolve the globbing twice. Once for
item_set_perms() and once for item_set_xattr(). I think it would be
better to do this in one call.

>  
>  case RECURSIVE_RELABEL_PATH:
> @@ -901,8 +996,12 @@ static int create_item(Item *i) {
>  r = glob_item(i, item_set_perms_recursive);
>  if (r < 0)
>  return r;
> -
>  break;
> +
> +case SET_XATTR:
> +r = item_set_xattrs(i, i->path);
> +if (r < 0)
> +return r;
>  }


Misses the closing "break;"?

Looks OK otherwise.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Service not restarting after Condition failed

[Lennart Poettering]

On Thu, 30.10.14 18:47, D.S. Ljungmark (spi...@aanstoot.se) wrote:

> Hi
>  we have a service set to:
> ConditionFileNotEmpty=
> 
> and
> 
> Restart=Always
> 
> 
> This combination would (in my feebled mind) cause the service to restart
> once the Condition was fulfilled, but that doesn't seem to be the
> case.

Conditions are something that are on-time evaluated right before we
would start a unit, and cause this starting to be shortcut. That's all
really. Restarts are only triggered when a running service dies, and
the start job queued by that will then check the conditions again. If
the condition doesn't hold then this start will not be executed, and
hence no restart ever again either...

> Is there a way I can get a service to restart even after it has been set
> as inactive (dead) "start condition failed"?

Nope, conditions are not for that. For the specific check of
file-not-empty there's no nice way to handle this, however for
directory-not-empty you could set up DirectoryNotEmpty=...

> Should I simply remove the Condition, or something else?

What precisely are you trying to do?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Poor man's reboot doesn't work

[Lennart Poettering]

On Mon, 10.11.14 22:30, Thomas Meyer (tho...@m3y3r.de) wrote:

> Am Freitag, den 07.11.2014, 01:59 +0100 schrieb Lennart Poettering:
> > On Sun, 02.11.14 12:48, Thomas Meyer (tho...@m3y3r.de) wrote:
> > 
> > > Hi,
> > > 
> > > I tried to switch to the emergency target and back to the graphical 
> > > target,
> > > but this doesn't seem to work.
> > > 
> > > Should this work, i.e.?
> > > 
> > > # systemctl isolate emergency.target
> > > # systemctl isolate graphical.target
> > > 
> > > The services seems to fail with this error once I'm in the 
> > > emergency.target
> > > and try to switch back to the graphical.target:
> > > status=219/CGROUP
> > 
> Mhh, strange. the last two tries to reproduces this bug failed.
> everything worked as expected. Strange!
> 
> anyway I'm going to upgrade to Fedora 21 in the next days. so I'll watch
> out for this bug again, then.

This really feels like a race. Something is removing the cgroup before
we can add the process to the cgroup. One way to track this down might
be to use Martin Pitt's "fatrace" tool to check which process is
removing the cgroup ultimately.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [systemd-commits] units/basic.target units/poweroff.target units/reboot.target

[Lennart Poettering]

On Thu, 06.11.14 14:44, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> On Thu, Nov 06, 2014 at 02:28:12PM +0100, Lennart Poettering wrote:
> > On Thu, 06.11.14 12:45, Patrick Häcker (pa...@web.de) wrote:
> > 
> > > > > However, this one appears bogus to me. Is there any such software
> > > > > around that really does this? And if so, this really appears weird to
> > > > > me to support. Delaying shutdown for more than 30min is just wrong.
> > > > Isn't this what the various "download updates and reboot" gnome-y
> > > > things are doing?
> > > At least unattended-upgrades from Debian/Ubuntu/... can be configured to 
> > > install updates on shutdown (without any special mode or something). And, 
> > > yes, this can run for more than 30 minutes, which I could already observe 
> > > in 
> > > its default mode (installing during normal system activities), so I see 
> > > no 
> > > reason why this should not happen when configured to install during 
> > > shutdown. 
> > > The reason is, that unattended-upgrades can basically update the whole 
> > > distribution to the next version, which naturally can take a lot of time.
> > > 
> > > It's questionable if this is a sane setup, but I can think of setups 
> > > where 
> > > this might be useful, e.g. having two identically configured servers for 
> > > redundancy reasons where one server would be enough. Then it might make 
> > > sense 
> > > to update one system during shutdown while the other one takes over. This 
> > > has 
> > > the advantage, that normally running servers either have the old or the 
> > > new 
> > > state, but never some intermediate state during the update. The shutdown 
> > > time 
> > > does not really matter in this case and a watchdog killing the system 
> > > wouldn't be welcome. But all in all this seems like an exotic use
> > > case.
> > 
> > Is "unattended-upgrades" a package of its own? If so, I'd probably ask
> > the packagers to include drop-ins for reboot.target to override the
> > timeout. That way, as soon as you install it the shutdown timeouts are
> > disabled.
>
> That is suboptimal. There really should be a way to this dynamically, like 
> saying:
> I'm a log-running job, I need more time, but everything is still fine. This
> type of status should require periodical pings, watchdog style. Let's say that
> the backup job run during shutdown hangs because there's no network, we want
> to shutdown at some point anyway.

So, we always had per-unit timeouts in place, and they are opt-out
(with the exception of Type=oneshot services where they are
opt-in).  Hence adding a second level of opt-out timeouts doesn't
sound particularly attractive to me.

The reason I added the system-wide startup/shutdown timeouts was
really to be a safety net, so that the individual per-unit timeouts
and the opted-out exceptions don't add up beyond bounds.

The specific usecase I had for this (beyond the obvious one in
embedded/HA setups) was my Lenovo Yoga laptop. It has the power button
on the outside, that is reachable even when the laptop is closed (this
is due the fact that it is convertible into tablet mode, where the
button needs to stay accessible). Now, if the system is suspended, and
the lid closed, and the power button is accidentally hit because the
laptop was stuffed in a backpack, then since a couple of versions ago
is not a problem: after a short while the system will suspend
again. However, if the machine is powered off with the lid closed, and
the power-button is hit the machine powers up currently, then boots up
until the LUKS prompt is hit and then just hangs there, forever,
heating up my backpack, so then when I finally unpack it the battery
is completely empty. I figure this is not only an issue with laptops
like the Yoga but in general with all kinds of devices. 

Now, the question is what we can do now about this:

a) we could move logind into early boot. This has multiple problems
   though: it would need to track system state as gettys on other ttys
   should only be started in multi-user mode, not in early boot. Also,
   the behaviour would probably not be ideal: i think it would be
   preferable if the system shuts down rather then suspend if we hang
   during boot.

b) specifically do something about LUKS prompt timeouts: when a very
   long timeout is hit for essential devices we could simply turn off
   the machine again. This would fix my immediate problem, but I am
   not sure I like it too much, I think other hangs should really be
   covered too...

c) we can come up with a scheme that explicitly excludes fsck, selinux
   relabel and so on from the overall-timeout. Sounds messy and
   non-obvious given that they all have individual timeouts
   anyway... Two layers of opting out of timeouts sounds suspicious?

Any other ideas?
   
Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedeskto

Re: [systemd-devel] Should systemd-logind provide a DM-independent mechanism for handling guest accounts?

[Lennart Poettering]

On Mon, 10.11.14 16:41, Laércio de Sousa 
(laercioso...@sme-mogidascruzes.sp.gov.br) wrote:

> Hi there!
> 
> Currently there are few alternatives for implementing guest accounts in
> Linux systems. I know only two: an AppArmor-based approach implemented in
> LightDM, and a SELinux-based approach implemented in Fedora's package
> "xguest" that works with GDM. There's no option for console guest login
> (should it be needed?).
> 
> I was thinking if systemd-logind could handle itself guest accounts in the
> future, making it available for use by any display manager (and even
> console logins, who knows?).
> 
> What do you think about it?

I figure this pays into the whole concept of dynamic users, which we
really want to have eventually, to deal with dynamic allocation of
UIDs for user namespacing in container managers, for allocating
per-seat users for gdm login screens, and then also for your usecase,
i.e. to implement guest users that go away entirely on logout.

So yeah, it's definitely something we want, and I figure it should be
added to the systemd project in some way.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Poor man's reboot doesn't work

[Thomas Meyer]

Am Freitag, den 07.11.2014, 01:59 +0100 schrieb Lennart Poettering:
> On Sun, 02.11.14 12:48, Thomas Meyer (tho...@m3y3r.de) wrote:
> 
> > Hi,
> > 
> > I tried to switch to the emergency target and back to the graphical target,
> > but this doesn't seem to work.
> > 
> > Should this work, i.e.?
> > 
> > # systemctl isolate emergency.target
> > # systemctl isolate graphical.target
> > 
> > The services seems to fail with this error once I'm in the emergency.target
> > and try to switch back to the graphical.target:
> > status=219/CGROUP
> 
Mhh, strange. the last two tries to reproduces this bug failed.
everything worked as expected. Strange!

anyway I'm going to upgrade to Fedora 21 in the next days. so I'll watch
out for this bug again, then.

thanks.
thomas

> Hmm, this is certainly weird.
> 
> Any chance you can do "strace -ff -p 1 -o /tmp/someplace/log" (maybe
> from the debug shell). Then, trigger the issue again, and find the
> tight log file in /tmp/someplace that ends with an exit(219). It would
> be good to paste that file somewhere (or at least the last few lines
> which might give an indication on what precisely fails), so that I can
> have a look.
> 
> Also, try booting with debug logs on ("systemd.log_level=debug") and
> see if this generates any additional log output that might be useful.
> 
> Lennart
> 



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

Re: [systemd-devel] udevd and "quiet"

[Colin Guthrie]

Lennart Poettering wrote on 10/11/14 18:54:
> On Mon, 10.11.14 10:11, Colin Guthrie (gm...@colin.guthr.ie) wrote:
> 
>> Hi,
>>
>> Not sure how long this has been the case, but in a dracut initrd that is
>> NOT using systemd, udevd will print out "starting version 217" even when
>> "quiet" is used on the command line.
> 
> Hmm, that message is printed at LOG_INFO log level. "quiet" should
> normally turn that off, but leave LOG_NOTICE and worse shown.

Well according to:

shared/log.c:880: * However, "quiet" is only parsed by PID 1!

it seems that "quiet" is only parsed by PID 1, so this shouldn't affect
udevd running on it's own outside of systemd as PID 1 (which can be the
case in dracut - slowly working towards systemd in dracut but haven't
got the time/energy to debug all the crazy disk configurations our
installer lets you imagine up...).

> Are you saying that doesn't work correctly?

It certainly appears not to work for udevd, and looking at the code in
src/udev/udevd.c makes this rather obvious.

Line 1119:
log_set_target(LOG_TARGET_AUTO);
log_parse_environment();
log_open();

udev_set_log_fn(udev, udev_main_log);
log_set_max_level(udev_get_log_priority(udev));


So after setting the log level from the environment, we also set it from
udev_get_log_priority() which, since
2004d23a0fcaa6e74631057a2ff75594a038d86e will ultimately return LOG_INFO
if no other factors interfere.

So regardless of SYSTEMD_LOG_LEVEL environment var, the built in log
level will always override it, whether this is LOG_INFO or overridden by
/etc/udev/udev.conf or UDEV_LOG env var.

IMO this should be fixed. Probably the simplest fix that retains
backwards compatibility is this (untested) which honours
SYSTEMD_LOG_LEVEL but still prefers UDEV_LOG:

diff --git a/src/libudev/libudev.c b/src/libudev/libudev.c
index b1649b6..127b85c 100644
--- a/src/libudev/libudev.c
+++ b/src/libudev/libudev.c
@@ -207,6 +207,8 @@ _public_ struct udev *udev_new(void)

 /* environment overrides config */
 env = secure_getenv("UDEV_LOG");
+if (isempty(env))
+env = secure_getenv("SYSTEMD_LOG_LEVEL");
 if (env != NULL) {
 int prio;



But AFAICT all this still doesn't prevent "quiet" on the kernel command
line having zero effect on udevd's default log level :)

So either we teach udevd to parse quiet itself when setting it's default
log level or we simply fix dracut to set UDEV_LOG env var to ensure the
log level is set, as it expects, set to err (it could write a
/etc/udev/udev.conf but env var is easier). I posted such a dracut patch
to the initramfs@vger list earlier today.

http://thread.gmane.org/gmane.linux.kernel.initramfs/3879

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] s/commandline/command line/g

[Jason St. John]

On Thu, Nov 6, 2014 at 9:37 AM, Lennart Poettering
 wrote:
> On Wed, 05.11.14 14:56, har...@redhat.com (har...@redhat.com) wrote:
>
>> +++ b/man/systemd-run.xml
>> @@ -215,7 +215,7 @@ along with systemd; If not, see 
>> .
>>  
>>
>>  All command-line arguments after the first non-option
>> -argument become part of the commandline of the launched
>> +argument become part of the command line of the launched
>>  process. If a command is run as service unit, its first argument
>>  needs to be an absolute binary path.
>>
>
> I figure there are some more cleanups to be done here... The example
> above shows that we not only use "commandline" and "command line", but
> also "command-line"...
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel

"command-line" is the proper spelling when used as an adjective.
"command line" is correct when it is a noun.

For example, "command-line options" is correct, and "enter foo on the
command line" is also correct. But if you switch which example gets
the hyphen, then they are both grammatically *in*correct. In any case,
"commandline" is always incorrect.

A simple find and replace of "command-line" to "command line" will
introduce numerous grammatical errors.

Jason

P.S. Lennart, sorry for the duplicate email. I just realized that my
previous email was sent to you only instead of to the mailing list.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] user environment variables

[arnaud gaboury]

>> As for the variable, two more wishes (not a big deal yet):
>> - in units, why not add a specifier reflecting $XDG_CONFIG_HOME
>
> Hmm, when we start with that, then I figure people want the other XDG
> dirs as well, soon...
>
> Anyway, what's the usecase for this?

Just laziness when writing service files.conf
Ex: gpg-agent.conf
[Service]
Environment=GNUPGHOME=%h/.config/gnupg

I often use the path sequence '%h/.config'.
So forget about it, laziness is not a valuable reason


>
>> - why not systemctl --export-environment
>
> Same here, what's the usecase?

No usecase at the moment. I can imagine one day a systemctl started
service with an exported variable to systemd env and then need to pass
the variable to the user env for any other services.
Again, not yet a big deal.

>
> (Not really opposed to either, but I'd like to hear a usecase first)
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] generator logging during daemon-reload

[Lennart Poettering]

On Mon, 10.11.14 20:30, Alexandre Detiste (alexandre.deti...@gmail.com) wrote:

> >> Yes, but then the log appears as a ugly big chunck without the
> >> timestamp & host on the left; 
> > > except the first line. Is it ok to reopen /dev/ksmg for each line
> > > writen to avoid this ?
> > 
> > Not sure I follow?
> 
> This might be a trivial problem; it's just that there are really few people
> writing generators or outputing do /dev/kmsg .
> 
> Here is a sample test case the 2 different behaviours,
> maybe a "flush" after the "write" would do it:
> 
> root@antec:/home/tchet# cat log
> <4> log1: log1
> <4> log2: log2
> <4> log3: log3
> <4> log4: log4
> root@antec:/home/tchet# LANG=C dd if=log of=/dev/kmsg
> 0+1 records in
> 0+1 records out
> 60 bytes (60 B) copied, 0.000114992 s, 522 kB/s
> root@antec:/home/tchet# while read level pgm msg; do echo $level $pgm $msg > 
> /dev/kmsg; done < log
> root@antec:/home/tchet# journalctl -n
> ...
> nov 10 20:25:06 antec log1: log1
> <4> log2: log2
> <4> log3: log3
> <4> log4: log4
> nov 10 20:25:20 antec log1: log1
> nov 10 20:25:20 antec log2: log2
> nov 10 20:25:20 antec log3: log3
> nov 10 20:25:20 antec log4: log4

The kernel does some moronic line merging there. Consider just
reopening the device each time to avoid it...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Shutdown problems

[Lennart Poettering]

On Sat, 08.11.14 11:16, Nikolaus Rath (nikol...@rath.org) wrote:

> > Please boot with "systemd.log_level=debug", then make the machine hang
> > and check what the last things in the logs say. Maybe then paste that
> > somewhere online and post the URL for that here, so that we can have a
> > look.
> 
> Here's the output (obtained by changing log level and remounting earlier
> in the debug.sh script):
> 
> https://dl.dropboxusercontent.com/u/11545826/shutdown.log
> 
> Thanks for your help!

Hmm the logs show that systemd pretty much completed its
shutdown. After the message "Cannot finalize remaining DM devices,
continuing." the only thing that still runs is the shutdown hooks you
used to generate this log, plus either a jump back into your initrd
(if your initrd supports that) or the reboot() system call. 

If the latter hangs then it's a kernel bug.

Please check if there are any other scripts in
/lib/systemd/system-shutdown/ that might be at fault here.

Please check if your initrd is one of those which support jumping back
into the initrd on shutdown. For that check if /run/initramfs/shutdown
exists during runtime and is executable. If so, it's probably an
initrd problem, please file a bug against your initrd implementation.

You appear to be using LVM, I wouldn't be surprised if LVM is broken
here, but I cannot help you debugging this, please contact the LVM
maintainers in this case.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] generator logging during daemon-reload

[Alexandre Detiste]

>> Yes, but then the log appears as a ugly big chunck without the
>> timestamp & host on the left; 
> > except the first line. Is it ok to reopen /dev/ksmg for each line
> > writen to avoid this ?
> 
> Not sure I follow?

This might be a trivial problem; it's just that there are really few people
writing generators or outputing do /dev/kmsg .

Here is a sample test case the 2 different behaviours,
maybe a "flush" after the "write" would do it:

root@antec:/home/tchet# cat log
<4> log1: log1
<4> log2: log2
<4> log3: log3
<4> log4: log4
root@antec:/home/tchet# LANG=C dd if=log of=/dev/kmsg
0+1 records in
0+1 records out
60 bytes (60 B) copied, 0.000114992 s, 522 kB/s
root@antec:/home/tchet# while read level pgm msg; do echo $level $pgm $msg > 
/dev/kmsg; done < log
root@antec:/home/tchet# journalctl -n
...
nov 10 20:25:06 antec log1: log1
<4> log2: log2
<4> log3: log3
<4> log4: log4
nov 10 20:25:20 antec log1: log1
nov 10 20:25:20 antec log2: log2
nov 10 20:25:20 antec log3: log3
nov 10 20:25:20 antec log4: log4
 
> Yes, that's really not an OK thing to do. /usr/sbin/sendmail ...
Ok, I don't want to test this with 20 differents MTA anyway.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [systemd-commits] units/basic.target units/poweroff.target units/reboot.target

[Lennart Poettering]

On Thu, 06.11.14 16:59, Colin Guthrie (gm...@colin.guthr.ie) wrote:

> Simon McVittie wrote on 06/11/14 15:21:
> > On 06/11/14 14:16, Zbigniew Jędrzejewski-Szmek wrote:
> >> > What matters is how it is all arranged:
> >> > 
> >> > - if there's a job that does stuff, and then calls reboot or shutdown
> >> > - a hook into the shutdown or reboot target does some work
> > unattended-upgrades is currently the latter: the user shuts down (or is
> > reminded to shut down by an update notification), and
> > unattended-upgrades runs as a side-effect.
> > 
> > This is an optional (non-default) configuration of an optional package,
> > not core Debian/Ubuntu functionality; so it doesn't necessarily have to
> > be like this forever, it could be modified to tell systemd "I'm still
> > shutting down, continue to wait" periodically, it could be modified to
> > use "reboot into a special mode, install, then reboot again" logic under
> > systemd if that's something you already have, and, worst-case, it could
> > install a drop-in to override the timeout.
> 
> Was there not talk of teaching the sd-notify protocol the ability to
> tell systemd that "I'm still alive and doing stuff - so please don't
> kill me"?

That exists since quite some time. It's the WATCHDOG= field in sd_notify()

Not sure if this is really useful here though...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] user environment variables

[Lennart Poettering]

On Fri, 07.11.14 20:40, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:

> >
> > We could probably at least open up DefaultEnvironment= to specifier
> > expansion, so that %t would work the same way as in unit files. I
> > added a TODO list item for this now.
> >
> 
> Thank you so much < This refers to the recent flame about systemd.
> As a newbie, I can testify the dev team is doing everything to help.
> 
> As for the variable, two more wishes (not a big deal yet):
> - in units, why not add a specifier reflecting $XDG_CONFIG_HOME

Hmm, when we start with that, then I figure people want the other XDG
dirs as well, soon...

Anyway, what's the usecase for this?

> - why not systemctl --export-environment

Same here, what's the usecase?

(Not really opposed to either, but I'd like to hear a usecase first)

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] shared: explicitly ignore the return value of wait_for_terminate

[Lennart Poettering]

On Sun, 09.11.14 15:51, Ronny Chevalier (chevalier.ro...@gmail.com) wrote:

> CID#1237532
> CID#1237523
> CID#1237522

Applied! Thanks!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v2] shared/install: when unit contains only Also=, report 'indirect'

[Lennart Poettering]

On Fri, 07.11.14 21:21, Jan Synacek (jsyna...@redhat.com) wrote:

> If a unit contains only Also=, with no Alias= or WantedBy=, it shouldn't
> be reported as static. New 'indirect' status shall be introduced.

Thanks! Applied!

(Made one more commit afterwards changing the description of the new
unit file state a bit in the man page).

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] smack: introduce new SmackLabelExec option

[Lennart Poettering]

On Tue, 11.11.14 00:43, WaLyong Cho (walyong@samsung.com) wrote:

> On 11/10/2014 10:26 PM, Lennart Poettering wrote:
> > On Fri, 07.11.14 10:03, Casey Schaufler (ca...@schaufler-ca.com) wrote:
> > 
> >> Calling it SmackLabel= instead of SmackLabelExec= would be fine as
> >> far as I'm concerned. SmackLabel= is more consistent with SELinuxContext=
> >> and AppArmorProfile=, as you point out.
> > 
> > OK!
> > 
> > WaLyong, let's name it SmackLabel= then!
> 
> I think I had made you to bother. Excuse me, but I'm asking you again.
> And I think introducing new config should be careful.
> 
> Hmm, I'm still confusing. We're already using SmackLabel= as socket
> config item. Yeah, it can possible as both exec/socket config. But each
> purposes are different.
> In socket config, this config is used to set SMACK64 of socket file.
> In exec config, this config is used to set child systemd attribute when
> User= config is given.
> And does we have to explain each man page? Or drop from socket package
> and move that to exec page?

> I'm not sure it make sense.

Hmm, OK, so you might actually have a point. And this is because
.socket units may carry ExecStartPre= command lines which are execute
before we start listening to a socket. If we'd just have SmackLabel=
then it would not be clear whether it applies as file system label to
the socket fds, or if it applies as process label to the ExecStartPre=
processes.

Hmm, I guess I am fine with SmackLabelExec= then!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udevd and "quiet"

[Lennart Poettering]

On Mon, 10.11.14 10:11, Colin Guthrie (gm...@colin.guthr.ie) wrote:

> Hi,
> 
> Not sure how long this has been the case, but in a dracut initrd that is
> NOT using systemd, udevd will print out "starting version 217" even when
> "quiet" is used on the command line.

Hmm, that message is printed at LOG_INFO log level. "quiet" should
normally turn that off, but leave LOG_NOTICE and worse shown.

Are you saying that doesn't work correctly?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] generator logging during daemon-reload

[Lennart Poettering]

On Mon, 10.11.14 17:38, Alexandre Detiste (alexandre.deti...@gmail.com) wrote:

> Le lundi 10 novembre 2014, 14:32:49 Lennart Poettering a écrit :
> > > I know that generators should log to /dev/kmsg during early boot.
> > 
> > Correct!
> 
> Yes, but then the log appears as a ugly big chunck without the
> timestamp & host on the left; 

journalctl should pretty much generate the same output for userspace
messages written to /dev/kmsg then to those passed directly to journald.

> except the first line. Is it ok to reopen /dev/ksmg for each line
> writen to avoid this ?

Not sure I follow?

> So we should also avoid sending mail with /usr/sbin/sendmail , for example ?

Yes, that's really not an OK thing to do. /usr/sbin/sendmail might
talk to a local service for delivering the mail, as well as syslog
again for its own logging needs.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Should systemd-logind provide a DM-independent mechanism for handling guest accounts?

[Laércio de Sousa]

Hi there!

Currently there are few alternatives for implementing guest accounts in
Linux systems. I know only two: an AppArmor-based approach implemented in
LightDM, and a SELinux-based approach implemented in Fedora's package
"xguest" that works with GDM. There's no option for console guest login
(should it be needed?).

I was thinking if systemd-logind could handle itself guest accounts in the
future, making it available for use by any display manager (and even
console logins, who knows?).

What do you think about it?
-- 
*Laércio de Sousa*
*Orientador de Informática*
*Escola Municipal "Professor Eulálio Gruppi"*
*Rua Ismael da Silva Mello, 559, Mogi Moderno*
*Mogi das Cruzes - SPCEP 08717-390*
Telefone: (11) 4726-8313
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] generator logging during daemon-reload

[Alexandre Detiste]

Le lundi 10 novembre 2014, 14:32:49 Lennart Poettering a écrit :
> > I know that generators should log to /dev/kmsg during early boot.
> 
> Correct!

Yes, but then the log appears as a ugly big chunck without the timestamp & host 
on the left; 
except the first line. Is it ok to reopen /dev/ksmg for each line writen to 
avoid this ?

Google gave me this:
http://unix.stackexchange.com/questions/35639/how-can-i-write-to-dmesg-from-command-line

With take me back here :-) ! which is easy to understand.
http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journald-kmsg.c

> (...) deadlocks (...)
Ok, I indeed got some while doing tests for my /var/spool/cron/crontabs problem.

I finally settled to generate a kind of 'transient' service that does a 
"daemon-reload ; restart cront.target" _only_ 
if this path doesn't exist; and it iself contains a 
"ConditionDirectoryNotEmpty=/var/spool/cron/crontabs"
to avoid needless daemon-reload.

The twist: on the second run of the generator, this path now _does_ exist; 
so this service doesn't generate itself again.
At first, I had used 'ExecStartPost=' for the "restart part" ; 
but the .service simply vanish during the daemon-reload and can never finish.
(this behaves like a self-modifying shell script)

Now I do this, it turns the ExecStart in a kind of "atomic" operation:

  ExecStart=/bin/sh -c "/bin/systemctl daemon-reload ; /bin/systemctl 
try-restart cron.target"

https://github.com/systemd-cron/systemd-cron/blob/master/src/bin/systemd-crontab-generator#L471

> Generators really really shouldn't talk to any other services, and
> this means for logging they should log to /dev/kmsg or suchlike.

So we should also avoid sending mail with /usr/sbin/sendmail , for example ?

Thanks,

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

Re: [systemd-devel] [PATCH] smack: introduce new SmackLabelExec option

[WaLyong Cho]

On 11/10/2014 10:26 PM, Lennart Poettering wrote:
> On Fri, 07.11.14 10:03, Casey Schaufler (ca...@schaufler-ca.com) wrote:
> 
>> Calling it SmackLabel= instead of SmackLabelExec= would be fine as
>> far as I'm concerned. SmackLabel= is more consistent with SELinuxContext=
>> and AppArmorProfile=, as you point out.
> 
> OK!
> 
> WaLyong, let's name it SmackLabel= then!

I think I had made you to bother. Excuse me, but I'm asking you again.
And I think introducing new config should be careful.

Hmm, I'm still confusing. We're already using SmackLabel= as socket
config item. Yeah, it can possible as both exec/socket config. But each
purposes are different.
In socket config, this config is used to set SMACK64 of socket file.
In exec config, this config is used to set child systemd attribute when
User= config is given.
And does we have to explain each man page? Or drop from socket package
and move that to exec page?

I'm not sure it make sense.

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

Re: [systemd-devel] remount

[Lennart Poettering]

On Fri, 07.11.14 15:35, Fisher, Charles J. (Top Echelon) 
(charles.fis...@alcoa.com) wrote:

> When I start a container like this:
> 
> [root@limsdev ~]# systemd-nspawn -bD /home/limsbox --bind-ro=/usr/lib64 
> --bind-ro=/home/oracle/Ora12c/db
> 
> Is there any way I can stop the container root from being able to do this?:
> 
> ~ # mount -o remount,rw /usr/lib64

Disallowing that would mean taking CAP_SYS_ADMIN away from the
container. However that takes away quite a few different features,
including *any* kind of mounting. However, systemd relies on that to
properly implement PrivateTmp= and similar bits that require setting
up a mount namespace and bind mounting things within it.

That said, you actually can drop the cap, with the
--drop-capability=CAP_SYS_ADMIN switch, but YMMV.

Containers are really not about security, there are tons of security
holes in the entire scheme. We make this abundantly clear in the man
page of nspawn...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] generator logging during daemon-reload

[Lennart Poettering]

On Fri, 07.11.14 20:59, Alexandre Detiste (alexandre.deti...@gmail.com) wrote:

> Hi,
> 
> I know that generators should log to /dev/kmsg during early boot.

Correct!

> But, when they are restarted later by systemcl daemon-reload;
> is it better to write to the journal instead, by using systemd-cat for 
> example ?
> Or is it racy/forbidden ?

Yes, this is dangerous. During a "daemon-reload" PID 1 serilizes its
state to a file in /run, then flushes all configuration, then invokes
the generators, and then rereads the configuration and deserializes
the state. Now, if you generator accesses the journal socket, and
journald is not running yet (because you are in emergency mode for
example), then things might deadlock: as logging is synchronous and
the socket buffer is limited in size your generator might block while
writing the log message and since activation cannot take place as PID
1 is not processing any events while doing the whole state
flush/config flush/generator magic/config reload/state reload it would
never unblock again.

Generators really really shouldn't talk to any other services, and
this means for logging they should log to /dev/kmsg or suchlike.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] smack: introduce new SmackLabelExec option

[Lennart Poettering]

On Fri, 07.11.14 10:03, Casey Schaufler (ca...@schaufler-ca.com) wrote:

> Calling it SmackLabel= instead of SmackLabelExec= would be fine as
> far as I'm concerned. SmackLabel= is more consistent with SELinuxContext=
> and AppArmorProfile=, as you point out.

OK!

WaLyong, let's name it SmackLabel= then!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] smack: introduce new SmackLabelExec option

[WaLyong Cho]

On 11/10/2014 08:57 PM, Simon McVittie wrote:
> On 09/11/14 02:08, Casey Schaufler wrote:
>> Thus, dbus is a fine example where SMACK64EXEC is a bad idea. Because you
>> want a system bus and a user bus with different attributes you want it to get
>> the Smack label at launch time, just like you do for UID and capability sets.
> 
> I think there's a much more fundamental reason why SMACK64EXEC would be
> a bad idea for "dbus"[1], which is that dbus-daemon has not been
> designed to distrust its caller and prevent privilege escalation from
> its caller's privileges to its own privileges. I think an executable can
> only safely be setuid, or other frameworks' equivalents of setuid
> (setcap, SMACK64EXEC, etc.), if the developers of that executable are
> fully aware that it is a privilege boundary in that way, and are
> designing it (and choosing its library dependencies!) with that in mind.
> This is not the case for dbus-daemon.
> 
> It is entirely possible (although IMO unlikely) that, by coincidence,
> dbus-daemon does not currently have privilege escalations from its
> caller's privileges to its own privileges; but if we introduced such a
> thing (executing a command given by an environment variable, perhaps), I
> would not consider that to be a regression, because we never claimed it
> was suitable for that use.
> 
> This is not unique to dbus; it applies equally to any project that
> releases executables.
> 
> Note that dbus-daemon --system is designed to be a different sort of
> privilege boundary: it enforces differing privilege levels for
> applications that connect to it via D-Bus, and we do treat holes in that
> policy as security flaws. That still doesn't mean it is designed to be
> suitable for setuid.
> 
> S
> 
> [1] I assume you mean dbus-daemon, which is an executable; dbus is a
> package containing dbus-daemon, some other executables, and the libdbus
> library. There is no such thing as /usr/bin/dbus.
> 
Ah..dbus-daemon was just a example as a well known daemon. Actually,
this problem was occurred on email-service daemon. Currently, that has
"system::email" SMACK label. Please forgot I'd mentioned about
dbus-daemon. Currently, we are using daemon-daemon with "_" label like
other system daemon.

I wonder about other guys also confused about this.

Thanks
WaLyong

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

Re: [systemd-devel] [PATCH] smack: introduce new SmackLabelExec option

[Simon McVittie]

On 09/11/14 02:08, Casey Schaufler wrote:
> Thus, dbus is a fine example where SMACK64EXEC is a bad idea. Because you
> want a system bus and a user bus with different attributes you want it to get
> the Smack label at launch time, just like you do for UID and capability sets.

I think there's a much more fundamental reason why SMACK64EXEC would be
a bad idea for "dbus"[1], which is that dbus-daemon has not been
designed to distrust its caller and prevent privilege escalation from
its caller's privileges to its own privileges. I think an executable can
only safely be setuid, or other frameworks' equivalents of setuid
(setcap, SMACK64EXEC, etc.), if the developers of that executable are
fully aware that it is a privilege boundary in that way, and are
designing it (and choosing its library dependencies!) with that in mind.
This is not the case for dbus-daemon.

It is entirely possible (although IMO unlikely) that, by coincidence,
dbus-daemon does not currently have privilege escalations from its
caller's privileges to its own privileges; but if we introduced such a
thing (executing a command given by an environment variable, perhaps), I
would not consider that to be a regression, because we never claimed it
was suitable for that use.

This is not unique to dbus; it applies equally to any project that
releases executables.

Note that dbus-daemon --system is designed to be a different sort of
privilege boundary: it enforces differing privilege levels for
applications that connect to it via D-Bus, and we do treat holes in that
policy as security flaws. That still doesn't mean it is designed to be
suitable for setuid.

S

[1] I assume you mean dbus-daemon, which is an executable; dbus is a
package containing dbus-daemon, some other executables, and the libdbus
library. There is no such thing as /usr/bin/dbus.

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

Re: [systemd-devel] udevd and "quiet"

[Colin Guthrie]

Sorry for the "speaking to myself" spam.

Colin Guthrie wrote on 10/11/14 10:29:
> Colin Guthrie wrote on 10/11/14 10:11:
>> Hi,
>>
>> Not sure how long this has been the case, but in a dracut initrd that is
>> NOT using systemd, udevd will print out "starting version 217" even when
>> "quiet" is used on the command line.
>>
>> This isn't ideal as it should be mostly silent when quiet is used and
>> indeed this is the only output from the initrd.
>>
>> So question is, what is the correct fix.
>>
>> I don't really like the idea of udevd parsing "quiet" directly as this
>> should really only apply to pid1.
>>
>> So perhaps dracut (as PID1 at that stage) should parse the "quiet"
>> command line and set SYSTEMD_LOG_LEVEL=warning (or err?) before starting
>> udevd (it doesn't seem that udevd takes any --log-level= (and friends)
>> arguments, so the environment seems the only way).
>>
>> Is this the right approach or am I maybe missing something?
> 
> Hmm, this won't work it seems anyway, as right after
> log_parse_enviornment() and log_open() there is a call to:
> 
> 
> log_set_max_level(udev_get_log_priority(udev));
> 
> So it seems that an evnironment parsing is very swiftly overridden -
> which makes env parsing kinda pointless IMO.
> 
> Any thoughts?
> 
> CC'ing Tom as he changed the default log level to INFO recently in
> 2004d23a0fcaa6e74631057a2ff75594a038d86e which is likely why I'm seeing
> the bubble up now...

"recently" fail... I misread the year! :D

So looking at this further, it seems that dracut has kernel command line
options to tweak the log level of dracut via udevadm control. The fact
that it has an option to tweak it *to* info suggest that dracut assumes
it's something else, and I'd guess it assumes err.

So I think the correct behaviour here is to just set UDEV_LOG=err
unconditionally in dracut and let the udevadm control options kick in later.

Either that or a slight tweak to avoid the udevadm control altogether,
and just set UDEV_LOG correctly from the beginning but not sure how well
that works with older udev versions and whether or not UDEV_LOG env var
works with older udevs that are still supported?

Anyway, I guess this is one to follow up with Harald on the initramfs ML.

Col





-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udevd and "quiet"

[Colin Guthrie]

Colin Guthrie wrote on 10/11/14 10:11:
> Hi,
> 
> Not sure how long this has been the case, but in a dracut initrd that is
> NOT using systemd, udevd will print out "starting version 217" even when
> "quiet" is used on the command line.
> 
> This isn't ideal as it should be mostly silent when quiet is used and
> indeed this is the only output from the initrd.
> 
> So question is, what is the correct fix.
> 
> I don't really like the idea of udevd parsing "quiet" directly as this
> should really only apply to pid1.
> 
> So perhaps dracut (as PID1 at that stage) should parse the "quiet"
> command line and set SYSTEMD_LOG_LEVEL=warning (or err?) before starting
> udevd (it doesn't seem that udevd takes any --log-level= (and friends)
> arguments, so the environment seems the only way).
> 
> Is this the right approach or am I maybe missing something?

Hmm, this won't work it seems anyway, as right after
log_parse_enviornment() and log_open() there is a call to:


log_set_max_level(udev_get_log_priority(udev));

So it seems that an evnironment parsing is very swiftly overridden -
which makes env parsing kinda pointless IMO.

Any thoughts?

CC'ing Tom as he changed the default log level to INFO recently in
2004d23a0fcaa6e74631057a2ff75594a038d86e which is likely why I'm seeing
the bubble up now...

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] udevd and "quiet"

[Colin Guthrie]

Hi,

Not sure how long this has been the case, but in a dracut initrd that is
NOT using systemd, udevd will print out "starting version 217" even when
"quiet" is used on the command line.

This isn't ideal as it should be mostly silent when quiet is used and
indeed this is the only output from the initrd.

So question is, what is the correct fix.

I don't really like the idea of udevd parsing "quiet" directly as this
should really only apply to pid1.

So perhaps dracut (as PID1 at that stage) should parse the "quiet"
command line and set SYSTEMD_LOG_LEVEL=warning (or err?) before starting
udevd (it doesn't seem that udevd takes any --log-level= (and friends)
arguments, so the environment seems the only way).

Is this the right approach or am I maybe missing something?

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [gummiboot][RFC] Add trusted boot (tboot) support to gummiboot

[Alexander E. Patrakov]

10.11.2014 14:10, Minchev, Todor wrote:

Hello guys,

I have been working on adding trusted boot (tboot) support to gummiboot
and since this requires quite a bit of new code to be added to the
gummiboot code base I wanted to send it out for review and comments.

This is the new functionality that these patches add to the gummiboot
master branch:

- trusted boot support via the tboot module and Intel's Trusted
Execution Technology (TXT)
- partial multiboot2 support for passing data to the trusted boot module
- booting non efi_stub kernels via tboot
- no impact on the existing gummiboot functionality


I have not looked at the code, but looked at the list of commit 
messages. In particular:



   gummiboot: load the loadable segments of the ELF binary and jump
to its entry point address


As far as I understand, this goes against the design goals of gummiboot 
of being a simple wrapper that is able to execute EFI binaries and only 
them. Would it be feasible to convert tboot into an EFI binary instead, 
and measure/validate it as such, using the API provided by UEFI for that?


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

[systemd-devel] [gummiboot][RFC] Add trusted boot (tboot) support to gummiboot

[Minchev, Todor]

Hello guys,

I have been working on adding trusted boot (tboot) support to gummiboot
and since this requires quite a bit of new code to be added to the
gummiboot code base I wanted to send it out for review and comments. 

This is the new functionality that these patches add to the gummiboot
master branch:

- trusted boot support via the tboot module and Intel's Trusted
Execution Technology (TXT)
- partial multiboot2 support for passing data to the trusted boot module
- booting non efi_stub kernels via tboot
- no impact on the existing gummiboot functionality

Tboot
http://sourceforge.net/projects/tboot/

SINIT ACM
https://software.intel.com/en-us/articles/intel-trusted-execution-technology


The config for booting with tboot looks like this:

title tboot
multiboot2  /tboot
multiboot2_options  /tboot loglvl=all logging=serial,vga,memory
vga_delay=1 serial=115200,8n1,0x3f8
acm /acm
linux   /vmlinuz
initrd  /initrd
options root=UUID=c1f42944-05fe-40eb-99b6-4b79161113b5 nomodeset
console=tty0 console=ttyS0,115200n8


Thanks,

Todor




The following changes since commit
eb3daf2ca4cb1657cf1f780957485d690a552bf6:

  build-sys: build gummiboot executable only if HAVE_BLKID (2014-05-15
23:47:18 +0200)

are available in the git repository at:

  https://github.com/todorez/gummiboot-multiboot2.git multiboot2

for you to fetch changes up to 70f21ca5f7d9d8aa43e022e2e0b035a855875a48:

  gummiboot: fix multiboot2 header validation bug (2014-11-09 18:48:27
+)


Todor Minchev (15):
  gummiboot: add multiboot2 header option to the bootloader
  gummiboot: add whole and partial file loads
  gummiboot: load the loadable segments of the ELF binary and jump
to its entry point address
  gummiboot: add ELF validation and partial mbi2 population
  gummiboot: get EFI mmap and populate some of the MBI2 tags
  gummiboot: populate the cmdline, bootloader, modules,
system_table, efi mmap and end tags
  gummiboot: convert EFI mmap to E820 mmap
  gummiboot: add ACPI v1/v2 support
  gummiboot: add MBI2 framebuffer info
  gummiboot: add acm option to the config
  gummiboot: return the CPU to protected mode before tboot handover
  gummiboot: add a new config parameter for passing options to tboot
  gummiboot: add the kernel command line to the kernel module tag
  gummiboot: improve error reporting & fix indentation
  gummiboot: fix multiboot2 header validation bug

 Makefile.am  |   23 +-
 src/efi/gummiboot.c  |  105 ---
 src/elf/elf.c|  138 +
 src/elf/elf.h|  131 +
 src/elf/memcpy.c |  145 ++
 src/multiboot2/acpi.h|   26 ++
 src/multiboot2/multiboot2.c  | 1012

 src/multiboot2/multiboot2.h  |  345 ++
 src/multiboot2/multiboot2_util.h |  206 +
 9 files changed, 2085 insertions(+), 46 deletions(-)
 create mode 100644 src/elf/elf.c
 create mode 100644 src/elf/elf.h
 create mode 100644 src/elf/memcpy.c
 create mode 100644 src/multiboot2/acpi.h
 create mode 100644 src/multiboot2/multiboot2.c
 create mode 100644 src/multiboot2/multiboot2.h
 create mode 100644 src/multiboot2/multiboot2_util.h



smime.p7s
Description: S/MIME cryptographic signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel