Re: [systemd-devel] systemd-hostnamed/hostnamectl and transient hostname change

[Stef Walter]

On 30.04.20 10:43, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Apr 27, 2020 at 12:00:36PM +0200, Thomas HUMMEL wrote:
>> On 4/27/20 11:51 AM, Mantas Mikulėnas wrote:
>>
>> Hello, thanks for your answer.
>>
>>> On Mon, Apr 20, 2020 at 6:17 PM Thomas HUMMEL
>>> mailto:thomas.hum...@pasteur.fr>>
>>> wrote:
>>>
>>>1. why does the transient hostname change while I stated --static only
>>>while running hostnamectl ?
>>>
>>>2. why does the change take some time to appear on dbus ?
>>>
>>>
>>
>>> Hostnamed does not implement receiving hostname change
>>> notifications from the kernel, so it always reports you the same
>>> hostname that it has seen on startup.
>>
>> That was my understanding as well.
> 
> Lennart opened a PR to remove the caching:
> https://github.com/systemd/systemd/pull/15624.
> 
>>> You're only seeing changes because hostnamed /exits when idle/ --
>>> the next time you're actually talking to a brand new instance of
>>> hostnamed, which has seen the new hostname.
>>
>> But this does not explain why the transient hostname is changed as I
>> only changed the static one, does it ? Unless this new instance sets
>> it from the static one when it starts ? I mean something has to call
>> sethostname(2) to set the transient to the new static one, right ?
> 
> The documentation is wrong. The code in hostnamed sets the kernel
> hostname when setting the static one. This was changed in
> https://github.com/systemd/systemd/commit/c779a44222:
> 
> commit c779a44222161155c039a7fd2fd304c006590ac7
> Author: Stef Walter 
> Date:   Wed Feb 12 09:46:31 2014 +0100
> 
>hostnamed: Fix the way that static and transient host names interact
>
>It is almost always incorrect to allow DHCP or other sources of
>transient host names to override an explicitly configured static host
>name.
>
>This commit changes things so that if a static host name is set, this
>will override the transient host name (eg: provided via DHCP). Transient
>host names can still be used to provide host names for machines that have
>not been explicitly configured with a static host name.
>
>The exception to this rule is if the static host name is set to
>"localhost". In those cases we act as if no
>static host name has been explicitly set.
> 
> We need to reconcile the code and the docs. I'd go for updating the docs
> to match the code, because this is a long-standing behaviour and people
> haven't been complaining about it. (I'm assuming you're not unhappy, just
> confused by the unexpected results...). Opinions?

I'd support that. Obviously I should have included a docs patch in my
pull request :S

Stef

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

[systemd-devel] Regression: 'jounalctl -f -t unmatched' does not block

[Stef Walter]

Hi,

The Cockpit integration test suite caught a recent regression in
systemd. Using journalctl -f to follow unmatched criteria is broken.
More details here:

https://bugzilla.redhat.com/show_bug.cgi?id=1253649

Here's a patch:

https://github.com/systemd/systemd/pull/958

Stef



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] [PATCH] timedated: Add a LocalOffset property for timezone offset

[Stef Walter]

On 24.03.2015 15:22, Tom Gundersen wrote:
> On Tue, Mar 24, 2015 at 3:17 PM, Stef Walter  wrote:
>> On 24.03.2015 15:11, Kay Sievers wrote:
>>> On Tue, Mar 24, 2015 at 2:15 PM, Zbigniew Jędrzejewski-Szmek
>>>  wrote:
>>>> Exactly because they do not require being upgraded in lock-step, doing
>>>> conversion to the local time locally is "racy". Assuming we have up-to-date
>>>> timezone database locally, with the patch that was merged today we can
>>>> answer the question "what the local time should be remotely", but not
>>>> necessarily "what the local time is remotely".
>>>>
>>>> If we go to the trouble of displaying the remote local time, imho we
>>>> should do it as the remote does.
>>>
>>> No, we should care about the *state* of the system, and that is its
>>> time value and its configured location on earth.
>>
>> Then stop displaying incorrect "presentation" data in timedatectl.
> 
> I don't see how this is incorrect now. See below.
> 
>>> Systemd has no business in "fixing" the *presentation* logic of these
>>> values. It is not an API for the timezone database. These tools
>>> already exist.
>>>
>>> Please stop trying to add insufficient and half-thought-through APIs
>>> to cover problems which just do not exist in reality or do not need to
>>> be worked-around by systemd.
>>
>> This gives us what we need:
>>
>> $ date '+%s:%:z'
>>
>> So we'll use that instead of timedated. I'll update the wiki page for
>> the timedated DBus interface to note parts of it are just not remotable.
> 
> For the record, I think it IS remoteable now with the recent change.

It's better.

> It all comes down to what you intend the fields to mean. Now we mean
> the field to mean "the real localtime of the server (as seen from the
> client)", whereas you want it to mean "the localtime the server thinks
> it has". 

The latter is the only place where "server local time" is relevant. The
server's UTC time is the one that you can reason about, and display as
"client local time" ... in cases where you want to do that.

But when you're displaying "server local time" it should be according to
the server's zoneinfo.

For example in Cockpit (which again runs in a web browser) when you see:

 Server time: 2015-03-24 21:53
 Time zone: Australia/Tasmania

It means "the current time that the server thinks it is" ... not the
time the browser thinks it is ... not the time the browser thinks the
server should think it is ... But actually the time on the server, as
interpreted by the server.

Yes, I realize this is "presentation" data ...

> If these two notions don't coincide, something is obviously
> fucked,

That's the thing. It's not fucked. There will never be a time when all
zoneinfo's (and copies of moment-timezone.js [0] in our case) laying
around are identical.

But again, If you want to say this is out of scope of systemd, fine.
We'll just use the glibc linked into the remote /usr/bin/date to
interpret the *remote* zoneinfo for us, rather than the glibc linked
into timedated. It's a shame we have to spawn two processes instead of
one ... but so be it.

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

Re: [systemd-devel] [PATCH] timedated: Add a LocalOffset property for timezone offset

[Stef Walter]

On 24.03.2015 15:11, Kay Sievers wrote:
> On Tue, Mar 24, 2015 at 2:15 PM, Zbigniew Jędrzejewski-Szmek
>  wrote:
>> Exactly because they do not require being upgraded in lock-step, doing
>> conversion to the local time locally is "racy". Assuming we have up-to-date
>> timezone database locally, with the patch that was merged today we can
>> answer the question "what the local time should be remotely", but not
>> necessarily "what the local time is remotely".
>>
>> If we go to the trouble of displaying the remote local time, imho we
>> should do it as the remote does.
> 
> No, we should care about the *state* of the system, and that is its
> time value and its configured location on earth.

Then stop displaying incorrect "presentation" data in timedatectl.

> Systemd has no business in "fixing" the *presentation* logic of these
> values. It is not an API for the timezone database. These tools
> already exist.
> 
> Please stop trying to add insufficient and half-thought-through APIs
> to cover problems which just do not exist in reality or do not need to
> be worked-around by systemd.

This gives us what we need:

$ date '+%s:%:z'

So we'll use that instead of timedated. I'll update the wiki page for
the timedated DBus interface to note parts of it are just not remotable.

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

Re: [systemd-devel] [PATCH] timedated: Add a LocalOffset property for timezone offset

[Stef Walter]

/me hates the new thunderbird-enigmail

On 24.03.2015 14:15, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Mar 24, 2015 at 01:59:40PM +0100, Tom Gundersen wrote:
>> On Mon, Mar 23, 2015 at 8:13 PM, Stef Walter  wrote:
>>> Sorry about the encrypted email ... I hit the wrong button.
>>>
>>> On 23.03.2015 19:07, Shawn Landden wrote:
>>>> On Mon, Mar 23, 2015 at 8:56 AM, Kay Sievers  wrote:
>>>>> On Mon, Mar 23, 2015 at 3:49 PM, Stef Walter  wrote:
>>>>>> On 23.03.2015 15:26, Kay Sievers wrote:
>>>>>>> On Mon, Mar 23, 2015 at 1:46 PM, David Herrmann  
>>>>>>> wrote:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> On Mon, Mar 23, 2015 at 6:32 AM, Lennart Poettering
>>>>>>>>  wrote:
>>>>>>>>> On Thu, 19.03.15 14:39, David Herrmann (dh.herrm...@gmail.com) wrote:
>>>>>>>>>
>>>>>>>>>> Hmm, so this is a convenience call. You could just set tm.tm_zone
>>>>>>>>>> locally and use mktime() with the value retrieved by "Timezone"? 
>>>>>>>>>> Yeah,
>>>>>>>>>> the time-api is awful with global variables, but that's not really 
>>>>>>>>>> our
>>>>>>>>>> fault, is it?
>>>>>>>>>
>>>>>>>>> This would not work, as struct tm's .tm_zone field is not sufficient
>>>>>>>>> to indicate a timezone. The code would have to set $TZ and call 
>>>>>>>>> tzset().
>>>>>>>>
>>>>>>>> I see. The Unix-way of doing things!
>>>>>>>>
>>>>>>>>> Given the simplicity of this I'd probably just merge Stef's
>>>>>>>>> patch... It *is* kinda nice given that the timezone database is
>>>>>>>>> constantly updated and having this exposed on the bus so that it is
>>>>>>>>> accessible remotely has the benefit that you get the actual timezone
>>>>>>>>> information in effect on the remote system, and not a possible
>>>>>>>>> out-of-date timezone from the local database. If you follow what I 
>>>>>>>>> mean...
>>>>>>>>
>>>>>>>> ..locale data is also updated regularly but we don't export
>>>>>>>> locale-files on the bus ;)
>>>>>>>>
>>>>>>>> Anyway, if we add pseudo-redundant APIs, I'd go with a "LocalTime"
>>>>>>>> field as Shawn suggested. This is what the bus-user is interested in,
>>>>>>>> right? If they need more data (like DST), they should just parse
>>>>>>>> zoneinfo. And with "LocalTime" we avoid any ambiguity regarding DST.
>>>>>>>
>>>>>>> Transmitting several absolute time stamps sounds wrong.
>>>>>>> Transmitting the offset sounds as wrong as tz_minuteswest is and it got 
>>>>>>> killed
>>>>>>> for that reason.
>>>>>>>
>>>>>>> Why does anybody ever need anything else than the actual UTC time and
>>>>>>> the configured  timezone of the machine?
>>>>>>
>>>>>> Yes, we do. In Cockpit we want to show the server's local time, in the
>>>>>> server's timezone. This is similar to how GNOME shows you the local time
>>>>>> in the local timezone.
>>>>>>
>>>>>> But we don't have easy access to libc and its zoneinfo file parser from
>>>>>> javascript running in a browser. We do have access to DBus [0]
>>>>>
>>>>> But it is not systemd's task to cover for missing functionality in the
>>>>> cockpit architecture. We should not add redundant interfaces just
>>>>> provide data for a specific user.
>>>
>>> Even systemd can't reliably consume its own DBus timedated interface
>>> remotely. Even once timedatectl is fixed, the information will be wrong
>>> unless the version of zoneinfo and glibc are identical on both systems
>>> involved.
>>
>> Could you explain this? Is not the ABI stable here? Surely
>> zoneinfo/glibc are backwards compatible and do not require being
>> upgraded in lock-step, so how

Re: [systemd-devel] [PATCH] timedated: Add a LocalOffset property for timezone offset

[Stef Walter]

binNF286gWdVu.bin
Description: PGP/MIME version identification


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

Re: [systemd-devel] [PATCH] timedated: Add a LocalOffset property for timezone offset

[Stef Walter]

Sorry about the encrypted email ... I hit the wrong button.

On 23.03.2015 19:07, Shawn Landden wrote:
> On Mon, Mar 23, 2015 at 8:56 AM, Kay Sievers  wrote:
>> On Mon, Mar 23, 2015 at 3:49 PM, Stef Walter  wrote:
>>> On 23.03.2015 15:26, Kay Sievers wrote:
>>>> On Mon, Mar 23, 2015 at 1:46 PM, David Herrmann  
>>>> wrote:
>>>>> Hi
>>>>>
>>>>> On Mon, Mar 23, 2015 at 6:32 AM, Lennart Poettering
>>>>>  wrote:
>>>>>> On Thu, 19.03.15 14:39, David Herrmann (dh.herrm...@gmail.com) wrote:
>>>>>>
>>>>>>> Hmm, so this is a convenience call. You could just set tm.tm_zone
>>>>>>> locally and use mktime() with the value retrieved by "Timezone"? Yeah,
>>>>>>> the time-api is awful with global variables, but that's not really our
>>>>>>> fault, is it?
>>>>>>
>>>>>> This would not work, as struct tm's .tm_zone field is not sufficient
>>>>>> to indicate a timezone. The code would have to set $TZ and call tzset().
>>>>>
>>>>> I see. The Unix-way of doing things!
>>>>>
>>>>>> Given the simplicity of this I'd probably just merge Stef's
>>>>>> patch... It *is* kinda nice given that the timezone database is
>>>>>> constantly updated and having this exposed on the bus so that it is
>>>>>> accessible remotely has the benefit that you get the actual timezone
>>>>>> information in effect on the remote system, and not a possible
>>>>>> out-of-date timezone from the local database. If you follow what I 
>>>>>> mean...
>>>>>
>>>>> ..locale data is also updated regularly but we don't export
>>>>> locale-files on the bus ;)
>>>>>
>>>>> Anyway, if we add pseudo-redundant APIs, I'd go with a "LocalTime"
>>>>> field as Shawn suggested. This is what the bus-user is interested in,
>>>>> right? If they need more data (like DST), they should just parse
>>>>> zoneinfo. And with "LocalTime" we avoid any ambiguity regarding DST.
>>>>
>>>> Transmitting several absolute time stamps sounds wrong.
>>>> Transmitting the offset sounds as wrong as tz_minuteswest is and it got 
>>>> killed
>>>> for that reason.
>>>>
>>>> Why does anybody ever need anything else than the actual UTC time and
>>>> the configured  timezone of the machine?
>>>
>>> Yes, we do. In Cockpit we want to show the server's local time, in the
>>> server's timezone. This is similar to how GNOME shows you the local time
>>> in the local timezone.
>>>
>>> But we don't have easy access to libc and its zoneinfo file parser from
>>> javascript running in a browser. We do have access to DBus [0]
>>
>> But it is not systemd's task to cover for missing functionality in the
>> cockpit architecture. We should not add redundant interfaces just
>> provide data for a specific user.

Even systemd can't reliably consume its own DBus timedated interface
remotely. Even once timedatectl is fixed, the information will be wrong
unless the version of zoneinfo and glibc are identical on both systems
involved.

This is hardly Cockpit specific.

>> The data systemd provides over the bus is the the same as the running
>> system provides to the local user: the UTC time + the time zone.
>> Everything else should be a task of the presentation, in this case
>> cockpit.

The timezone timedated provides is in presentation format (ie:
"Australia/Tasmania"), a non-standard identifier, rather than a actual
information about the timezone. Unless all systems agree on these names
and have identical versions of the data (ie: zoneinfo), identical
algorithms for interpreting it (ie: glibc) it is impossible to correctly
interpret it remotely.

There are several DBus interfaces that possible not remotable, whether
intentionally or not.

For example NetwortkManager has byte[4] arrays stored in uint32's that
are completely unusable on a different architecture ... other DBus
interfaces have local file names as properties ... as so on.

We should mark the timedated interface as non-remotable or call out the
remotability problems in the documentation.

>> Yeah, it's currently a mix of local vs. remote data. If timedatctl
>> should work correctly on a remote host, it needs to fixed.
> I posted a patch for this.

With the current DBus interface, the only way to reliably fix this is to
exec timedatectl remotely on the other system and pipe the output data.
See above.

Stef

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

Re: [systemd-devel] [PATCH] timedated: Add a LocalOffset property for timezone offset

[Stef Walter]

binezjvUkOBeJ.bin
Description: PGP/MIME version identification


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

Re: [systemd-devel] [PATCH] timedated: Add a LocalOffset property for timezone offset

[Stef Walter]

On 23.03.2015 15:26, Kay Sievers wrote:
> On Mon, Mar 23, 2015 at 1:46 PM, David Herrmann  wrote:
>> Hi
>>
>> On Mon, Mar 23, 2015 at 6:32 AM, Lennart Poettering
>>  wrote:
>>> On Thu, 19.03.15 14:39, David Herrmann (dh.herrm...@gmail.com) wrote:
>>>
 Hmm, so this is a convenience call. You could just set tm.tm_zone
 locally and use mktime() with the value retrieved by "Timezone"? Yeah,
 the time-api is awful with global variables, but that's not really our
 fault, is it?
>>>
>>> This would not work, as struct tm's .tm_zone field is not sufficient
>>> to indicate a timezone. The code would have to set $TZ and call tzset().
>>
>> I see. The Unix-way of doing things!
>>
>>> Given the simplicity of this I'd probably just merge Stef's
>>> patch... It *is* kinda nice given that the timezone database is
>>> constantly updated and having this exposed on the bus so that it is
>>> accessible remotely has the benefit that you get the actual timezone
>>> information in effect on the remote system, and not a possible
>>> out-of-date timezone from the local database. If you follow what I mean...
>>
>> ..locale data is also updated regularly but we don't export
>> locale-files on the bus ;)
>>
>> Anyway, if we add pseudo-redundant APIs, I'd go with a "LocalTime"
>> field as Shawn suggested. This is what the bus-user is interested in,
>> right? If they need more data (like DST), they should just parse
>> zoneinfo. And with "LocalTime" we avoid any ambiguity regarding DST.
> 
> Transmitting several absolute time stamps sounds wrong.
> Transmitting the offset sounds as wrong as tz_minuteswest is and it got killed
> for that reason.
> 
> Why does anybody ever need anything else than the actual UTC time and
> the configured  timezone of the machine?

Yes, we do. In Cockpit we want to show the server's local time, in the
server's timezone. This is similar to how GNOME shows you the local time
in the local timezone.

But we don't have easy access to libc and its zoneinfo file parser from
javascript running in a browser. We do have access to DBus [0]

So obviously we could invent a DBus service called timedated2 (or
whatever) to do what we need ... but I figured I'd see if timedated
could do what we needed first.

It seems that timedatectl itself needs information about remote local
time, since when connecting remotely over DBus it gets the local time
wrong. [1]

Stef

[0] http://stef.thewalter.net/using-dbus-from-javascript-in-cockpit.html

[1]
http://lists.freedesktop.org/archives/systemd-devel/2015-March/029637.html


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

Re: [systemd-devel] [PATCH] timedated: Add a LocalOffset property for timezone offset

[Stef Walter]

On 23.03.2015 12:11, Shawn Landden wrote:
> On Sun, Mar 22, 2015 at 10:32 PM, Lennart Poettering
>  wrote:
>> On Thu, 19.03.15 14:39, David Herrmann (dh.herrm...@gmail.com) wrote:
>>
>>> Hmm, so this is a convenience call. You could just set tm.tm_zone
>>> locally and use mktime() with the value retrieved by "Timezone"? Yeah,
>>> the time-api is awful with global variables, but that's not really our
>>> fault, is it?
>>
>> This would not work, as struct tm's .tm_zone field is not sufficient
>> to indicate a timezone. The code would have to set $TZ and call tzset().
>>
>> Given the simplicity of this I'd probably just merge Stef's
>> patch... It *is* kinda nice given that the timezone database is
>> constantly updated and having this exposed on the bus so that it is
>> accessible remotely has the benefit that you get the actual timezone
>> information in effect on the remote system, and not a possible
>> out-of-date timezone from the local database. If you follow what I mean...
> The patch is COMPLETELY WRONG, as timezone offsets are differn't for
> differn't times due to DST. Even if this is taken into account there
> are all sorts of races
> with this information around DST switches.

As with the TimeUSec and RTCTimeUSec properties, it's assumed the caller
knows the information is out of date the instant they receive it.

But in that case I guess we shouldn't do
SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE...

> How about a
> "LocalTimeUSec" property, for those times that the application doesn't
> have an interest doing timezone calculations and just wants the local
> time on the other machine. 

That's fine with me. Although IMO it's quite unorthodox to have local
time in an integer value counted since the epoch.



Stef

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

Re: [systemd-devel] [PATCH] timedated: Add a LocalOffset property for timezone offset

[Stef Walter]

On 19.03.2015 15:17, David Herrmann wrote:
> Hi
> 
> On Thu, Mar 19, 2015 at 2:58 PM, Stef Walter  wrote:
>> On 19.03.2015 14:39, David Herrmann wrote:
>>> Hmm, so this is a convenience call. You could just set tm.tm_zone
>>> locally and use mktime() with the value retrieved by "Timezone"? Yeah,
>>> the time-api is awful with global variables, but that's not really our
>>> fault, is it?
>>>
>>> I'm not really against this bus-call, but I also don't see the point.
>>
>> In Cockpit we're running on a different machine, and accessing timedated
>> remotely. If this information is not available in timedated, we would
>> need to add another DBus service to expose this information.
>>
>> Besides it fits in well with the TimeUSec property.
> 
> But TimeUSec is UTC. If you retrieve "TimeUSec" and "Timezone", you
> can reconstruct the time offset yourself, without any further
> information, right?

No, the Timezone field is textual and unusable in a browser (unless you
reimplement all of /usr/share/zoneinfo in the browser).

>>> There's much more information in a timezone file than the offset, so
>>> why expose the offset but not the other data?
>>
>> I would like to be able to do 'timedatectl list-timezones' over DBus as
>> well.
> 
> Why? This information should be the same on all machines, right? I
> don't see why the remote list is of any interest.

Because Cockpit is running in a browser, and accesses DBus from a
browser. But I guess we could implement our own DBus timedated2
interface which exposes the zoneinfo information. I just figured
timedated would be a natural place for such an API.

>> Such work would allow timedatectl to work properly with the --host
>> argument. Currently the output of 'timedatectl status
>> --host=machine-in-another-timezone.example.com' is full of invalid
>> information.
> 
> Yes, but it's the job of timedatectl to print information in the
> timezone of the remote host, not of the local host. It should retrieve
> the "Timezone" field and modify it's local timezone if you want the
> information to be relative to remote timezone, not the local timezone
> (which I'm not sure you really want).
> 
> What exactly do you mean with "full of invalid information"?

Example below. First set of timedatectl output is correct (since I SSH
and then invoke timedatectl) ... second set has lots of incorrect
fields, since timedatectl accesses timedated remotely:

$ ssh 192.168.11.155 timedatectl
  Local time: Fr 2015-03-20 01:31:41 AEDT
  Universal time: Do 2015-03-19 14:31:41 UTC
RTC time: Do 2015-03-19 14:31:41
   Time zone: Australia/Tasmania (AEDT, +1100)
 NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
  DST active: yes
 Last DST change: DST began at
  So 2014-10-05 01:59:59 AEST
  So 2014-10-05 03:00:00 AEDT
 Next DST change: DST ends (the clock jumps one hour backwards) at
  So 2015-04-05 02:59:59 AEDT
  So 2015-04-05 02:00:00 AEST

$ timedatectl --host=192.168.11.155
  Local time: Do 2015-03-19 15:31:50 CET
  Universal time: Do 2015-03-19 14:31:50 UTC
RTC time: Do 2015-03-19 14:31:50
   Time zone: Australia/Tasmania (CET, +0100)
 NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
  DST active: no
 Last DST change: DST ended at
  So 2014-10-26 02:59:59 CEST
  So 2014-10-26 02:00:00 CET
 Next DST change: DST begins (the clock jumps one hour forward) at
  So 2015-03-29 01:59:59 CET
  So 2015-03-29 03:00:00 CEST



In particular the following fields are incorrect in the second set of
output:

  Local time: Do 2015-03-19 15:31:50 CET
   Time zone: Australia/Tasmania (CET, +0100)
 Last DST change: DST ended at
  So 2014-10-26 02:59:59 CEST
  So 2014-10-26 02:00:00 CET
 Next DST change: DST begins (the clock jumps one hour forward) at
  So 2015-03-29 01:59:59 CET
  So 2015-03-29 03:00:00 CEST


Cheers,

Stef



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] [PATCH] timedated: Add a LocalOffset property for timezone offset

[Stef Walter]

On 19.03.2015 14:39, David Herrmann wrote:
> Hi
> 
> On Thu, Mar 19, 2015 at 11:24 AM, Stef Walter  wrote:
>> This property is in usec (like the TimeUSec property) and allows
>> retrieving the timezone offset for the machine. This is particularly
>> usable for remote callers.
>> ---
>>  src/timedate/timedated.c | 20 +++-
>>  1 file changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
>> index ca771d5..e384b36 100644
>> --- a/src/timedate/timedated.c
>> +++ b/src/timedate/timedated.c
>> @@ -361,6 +361,22 @@ static int property_get_time(
>>  return sd_bus_message_append(reply, "t", now(CLOCK_REALTIME));
>>  }
>>
>> +static int property_get_local_offset(
>> +sd_bus *bus,
>> +const char *path,
>> +const char *interface,
>> +const char *property,
>> +sd_bus_message *reply,
>> +void *userdata,
>> +sd_bus_error *error)
>> +{
>> +struct tm *tm;
>> +time_t dummy = 0;
>> +
>> +assert_se(tm = localtime(&dummy));
>> +return sd_bus_message_append(reply, "t", (uint64_t)(tm->tm_gmtoff * 
>> 100));
>> +}
>> +
> 
> Hmm, so this is a convenience call. You could just set tm.tm_zone
> locally and use mktime() with the value retrieved by "Timezone"? Yeah,
> the time-api is awful with global variables, but that's not really our
> fault, is it?
> 
> I'm not really against this bus-call, but I also don't see the point.

In Cockpit we're running on a different machine, and accessing timedated
remotely. If this information is not available in timedated, we would
need to add another DBus service to expose this information.

Besides it fits in well with the TimeUSec property.

> There's much more information in a timezone file than the offset, so
> why expose the offset but not the other data?

I would like to be able to do 'timedatectl list-timezones' over DBus as
well.

Such work would allow timedatectl to work properly with the --host
argument. Currently the output of 'timedatectl status
--host=machine-in-another-timezone.example.com' is full of invalid
information.

Stef



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] [PATCH] timedated: Add a LocalOffset property for timezone offset

[Stef Walter]

This property is in usec (like the TimeUSec property) and allows
retrieving the timezone offset for the machine. This is particularly
usable for remote callers.
---
 src/timedate/timedated.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index ca771d5..e384b36 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -361,6 +361,22 @@ static int property_get_time(
 return sd_bus_message_append(reply, "t", now(CLOCK_REALTIME));
 }
 
+static int property_get_local_offset(
+sd_bus *bus,
+const char *path,
+const char *interface,
+const char *property,
+sd_bus_message *reply,
+void *userdata,
+sd_bus_error *error)
+{
+struct tm *tm;
+time_t dummy = 0;
+
+assert_se(tm = localtime(&dummy));
+return sd_bus_message_append(reply, "t", (uint64_t)(tm->tm_gmtoff * 
100));
+}
+
 static int property_get_ntp_sync(
 sd_bus *bus,
 const char *path,
@@ -440,7 +456,8 @@ static int method_set_timezone(sd_bus *bus, sd_bus_message 
*m, void *userdata, s
LOG_MESSAGE("Changed time zone to '%s'.", c->zone),
NULL);
 
-sd_bus_emit_properties_changed(bus, "/org/freedesktop/timedate1", 
"org.freedesktop.timedate1", "Timezone", NULL);
+sd_bus_emit_properties_changed(bus, "/org/freedesktop/timedate1", 
"org.freedesktop.timedate1",
+   "Timezone", "LocalOffset", NULL);
 
 return sd_bus_reply_method_return(m, NULL);
 }
@@ -666,6 +683,7 @@ static int method_set_ntp(sd_bus *bus, sd_bus_message *m, 
void *userdata, sd_bus
 static const sd_bus_vtable timedate_vtable[] = {
 SD_BUS_VTABLE_START(0),
 SD_BUS_PROPERTY("Timezone", "s", NULL, offsetof(Context, zone), 
SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
+SD_BUS_PROPERTY("LocalOffset", "t", property_get_local_offset, 0, 
SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
 SD_BUS_PROPERTY("LocalRTC", "b", bus_property_get_bool, 
offsetof(Context, local_rtc), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
 SD_BUS_PROPERTY("CanNTP", "b", bus_property_get_bool, 
offsetof(Context, can_ntp), 0),
 SD_BUS_PROPERTY("NTP", "b", bus_property_get_bool, offsetof(Context, 
use_ntp), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
-- 
2.3.3

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

Re: [systemd-devel] systemd DBus services exit when they have clients

[Stef Walter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14.11.2014 16:39, Lennart Poettering wrote:
> On Fri, 14.11.14 16:06, Stef Walter (st...@redhat.com) wrote:
> 
>>> I guess the idea is that many clients (e.g.
>>> gnome-settings-daemon) would make a few calls on startup and
>>> then continue running for days without ever touching the
>>> service again.
>>> 
>>> What are the actual problems caused by this? (I'm guessing 
>>> something might rely on `hostnamed` watching 
>>> /proc/sys/kernel/hostname, or things like that?)
>> 
>> In the case of Cockpit we have proxies that expose the properties
>> of DBus interfaces from the service. And you can watch that proxy
>> to see when stuff changes. When the service goes away the proxy
>> becomes invalid. Here's an example I just put together:
>> 
>> http://stef.thewalter.net/using-dbus-from-javascript-in-cockpit.html
>>
>>
>> 
But since Cockpit 0.31 we just ping the DBus service so it doesn't
>> feel lonely, and knows we're still interested ... for as long as
>> we're actually interested:
>> 
>> https://github.com/cockpit-project/cockpit/commit/aee825ef6d5ec4a6f8a4f25bc208b6f5ed4a9e96
>
>> 
> If you use proxies like that you should simply make sure they are
> not invalidated when the service goes away.
> 
> The services like hostnamed explicitly provide stable object paths
> and suchlike so that clients can completely ignore when the
> services go away and come back...

Most DBus services are not like that, and usually callers do need to
be aware of a service that goes away.

But I guess we could provide an option that instructs the proxy to
ignore a service's absence for use with systemd and any other
stateless services like this.

Stef
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlRmMdQACgkQe/sRCNknZa/ZJACg8FzwUH0iWtYBhS6uSpjzFimJ
7JwAn3sTe6S/VF5bqNI2kSH2c2VZ1B9K
=WZOu
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd DBus services exit when they have clients

[Stef Walter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14.11.2014 14:41, Mantas Mikulėnas wrote:
> On Fri, Nov 14, 2014 at 3:43 PM, Stef Walter  <mailto:st...@redhat.com>> wrote:
> 
> Is it intentional (or just laziness :D) that systemd DBus services 
> like hostnamed, timedated and friends all exit after a timeout
> even while callers that have invoked their methods are still on the
> bus?
> 
> Don't get me wrong, I like services that exit when not in use. But
> I sorta imagined 'not in use' as 'no more callers around'.
> 
> 
> I guess the idea is that many clients (e.g. gnome-settings-daemon)
> would make a few calls on startup and then continue running for
> days without ever touching the service again.
> 
> What are the actual problems caused by this? (I'm guessing
> something might rely on `hostnamed` watching
> /proc/sys/kernel/hostname, or things like that?)

In the case of Cockpit we have proxies that expose the properties of
DBus interfaces from the service. And you can watch that proxy to see
when stuff changes. When the service goes away the proxy becomes
invalid. Here's an example I just put together:

http://stef.thewalter.net/using-dbus-from-javascript-in-cockpit.html

But since Cockpit 0.31 we just ping the DBus service so it doesn't
feel lonely, and knows we're still interested ... for as long as we're
actually interested:

https://github.com/cockpit-project/cockpit/commit/aee825ef6d5ec4a6f8a4f25bc208b6f5ed4a9e96

> Maybe the services could have Subscribe() methods to cause them to
> stick around...

Yes also not a bad idea.

Stef

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlRmKJcACgkQe/sRCNknZa97ZgCfcW3XtPDHiN9kpfqukQp8Zncn
ioEAn3srFT3FMYFZsGkoVh1pUOERawuv
=Rn3k
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd DBus services exit when they have clients

[Stef Walter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Is it intentional (or just laziness :D) that systemd DBus services
like hostnamed, timedated and friends all exit after a timeout even
while callers that have invoked their methods are still on the bus?

Don't get me wrong, I like services that exit when not in use. But I
sorta imagined 'not in use' as 'no more callers around'.

In Cockpit we work around this by Ping()ing the services we want to
talk to (and get PropertiesChanged from) during our user session.

If this is a bug ... then maybe I'll look into coming up with a patch.

Stef
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlRmBv8ACgkQe/sRCNknZa9EOgCfVRDyI1GWvnMD6xgeLeSFFC1d
1EQAnROKAIUn6HKRQD9UWAQ+BUrhzGWs
=Z4LE
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Regression in v209: SIGKILL sent immediately after SIGTERM

[Stef Walter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 24.10.2014 01:51, Lennart Poettering wrote:
> On Fri, 12.09.14 11:57, Stef Walter (st...@redhat.com) wrote:
> 
>> This commit breaks cockpit orderly shutdown:
>> 
>>> commit 743970d2ea6d08aa7c7bff8220f6b7702f2b1db7 Author: Lennart
>>> Poettering  Date:   Fri Feb 7 16:12:09
>>> 2014 +0100
>>> 
>>> core: one step back again, for nspawn we actually can't wait
>>> for cgroups running empty since systemd will get exactly zero 
>>> notifications about it
>> 
>> The children of a cockpit login session all get SIGKILL
>> immediately after SIGTERM (less than a tenth of a second apart).
>> cockpit-agent and cockpit-session takes more than a tenth of a
>> second to shutdown cleanly.
>> 
>> The easiest way to reproduce this here, is a system shutdown.
>> Even the 'reboot' that started the system shutdown (executed via
>> ssh) gets a SIGKILL before it can exit().
>> 
>> Here's some output from a simple systemtap probe which
>> demonstrates this:
>> 
>> https://github.com/cockpit-project/cockpit/issues/1155#issuecomment-55374240
>>
>>
>> 
Here you can see how a cockpit unit, its login session scope, unit file,
>> unit properties:
>> 
>> https://github.com/cockpit-project/cockpit/issues/1155#issuecomment-55381385
>>
>>
>> 
This commit was introduced in v209, so (for example) the problem is
>> present in Fedora 21. Reverting the commit resolves the problem.
> 
> Well, this is a whack-a-mole game: there's currently no reliable
> way to get notifications when scopes run empty. In some situations
> we get them in others we don't, hence we better not wait for them.
> 
> I am not entirely sure though why this is a problem for cockpit?

Because our entire user session gets a SIGKILL immediately. Which
obviously could lead to data loss.

> Cockpit opens its own PAM sessions, has its own PAM session client 
> code? What's the current logic for ending such a session? Do you 
> properly invoke the PAM session end hooks? Can you elaborate on
> the way cockpit currently uses PAM?

Here's our call to pam_close_session().

https://github.com/cockpit-project/cockpit/blob/master/src/ws/session.c#L974

For local sessions, we use a process called cockpit-session to "do"
our PAM stack and switch to the right user.

The cockpit-session process starts calls pam_open_session() and then
forks cockpit-bridge, which in turn forks other user processes. When
cockpit-bridge exits or terminates on a signal, cockpit-session
session process calls pam_close_session(). Nothing fancy.

In fact the exact same issue happens when sshd opening/closing the
session and launching cockpit-bridge. So it's unlikely this has
anything to do with our PAM code.

With systemd v209 and later everything in the user session all its
children get SIGKILL immediately after SIGTERM. In fact the two
signals come so fast after each other that they sometimes seem to race
(well at least the logging of the events do ... hard to tell).

Stef
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlRJ++oACgkQe/sRCNknZa+PfQCgrV4/3cktyUqxm+IpKvIdkVuV
V0MAnjtooH1SFXctiqHJm+M7aWPiX5eY
=BUCO
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Regression in v209: SIGKILL sent immediately after SIGTERM

[Stef Walter]

This commit breaks cockpit orderly shutdown:

> commit 743970d2ea6d08aa7c7bff8220f6b7702f2b1db7
> Author: Lennart Poettering 
> Date:   Fri Feb 7 16:12:09 2014 +0100
>
> core: one step back again, for nspawn we actually can't wait for
> cgroups running empty since systemd will get exactly zero
> notifications about it

The children of a cockpit login session all get SIGKILL immediately
after SIGTERM (less than a tenth of a second apart). cockpit-agent and
cockpit-session takes more than a tenth of a second to shutdown cleanly.

The easiest way to reproduce this here, is a system shutdown. Even the
'reboot' that started the system shutdown (executed via ssh) gets a
SIGKILL before it can exit().

Here's some output from a simple systemtap probe which demonstrates this:

https://github.com/cockpit-project/cockpit/issues/1155#issuecomment-55374240

Here you can see how a cockpit unit, its login session scope, unit file,
unit properties:

https://github.com/cockpit-project/cockpit/issues/1155#issuecomment-55381385

This commit was introduced in v209, so (for example) the problem is
present in Fedora 21. Reverting the commit resolves the problem.

Cheers,

Stef

[1] Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1141137
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Work on adding polkit support to systemd1

[Stef Walter]

On 01.09.2014 11:47, David Herrmann wrote:
> Hi
> 
> On Mon, Sep 1, 2014 at 9:51 AM, Stef Walter  wrote:
>> On 18.08.2014 18:22, Lennart Poettering wrote:
>>> I have now pushed this, after reworking this on top some major changes
>>> to bus_verify_polkit(), which avoids having to pass the original
>>> callbacks through to the function that ultimately does the verification.
>>>
>>> While merging I also made another change, you are probably not going to
>>> like: I turned of the interactivity for the polkit checks. Interactivity
>>> needs to be optional, and it currently is for all out polkit-enabled bus
>>> methods. And we should do the same for the PID 1 offered methods.
>>
>> Ugh.
>>
>>> Now, of course, we should open this up for inetractive (after all,
>>> that's what polkit is good for), but we probably need a new set of
>>> methods for that, which take the original arguments but also take a
>>> boolean argument to enable ineractivity. Hence, we probably should have
>>> StartUnit2() in addition to StartUnit().
>>
>> That seems ugly. I think we should either:
>>
>>  * Have a method which we can invoke to make a client opt into
>>interactive polkit prompting for any invoked method.
>>
>>  * Version all the org.freedesktop.systemd1.Manager to
>>org.freedesktop.systemd1.Manager2 or something like that and support
>>both interfaces.
> 
> We had the idea to reserve a single bit in the dbus message header for
> that. See the discussion on the dbus-ML:
> http://lists.freedesktop.org/archives/dbus/2014-August/016294.html

Thanks.

> It looks like the most sane way to resolve this issue, imho.

I guess so. Makes a lot of sense.

We'll need to see how backportable this ends up being for all of
libdbus, gdbus ... of hand it doesn't that seem *that* invasive if it's
just a flag.

Otherwise (for Cockpit) we'll end up doing the brain-dead wrapping all
systemd APIs with yet another daemon that just does interactive polkit
authentication :S

Will keep an eye on this.

Cheers,

Stef

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

Re: [systemd-devel] Work on adding polkit support to systemd1

[Stef Walter]

On 18.08.2014 18:22, Lennart Poettering wrote:
> On Fri, 15.08.14 19:28, Stef Walter (st...@redhat.com) wrote:
> 
>>
>> On 15.08.2014 18:56, Lennart Poettering wrote:
>>> On Fri, 15.08.14 18:25, Stef Walter (st...@redhat.com) wrote:
>>>
>>>>
>>>> On 13.08.2014 20:27, Lennart Poettering wrote:
>>>>> On Wed, 06.08.14 13:23, Stef Walter (st...@redhat.com) wrote:
>>>>>
>>>>>> I've done initial work on adding polkit support to systemd1 DBus
>>>>>> methods. You can see it here:
>>>>
>>>> Thanks for the review. Worked on this a bit more.
>>>>
>>>> I might drop off the face of the earth for a couple weeks. In case I do,
>>>> I thought I'd update my public branch. But if I'm around, I'll test and
>>>> prepare a patch set early next week.
>>>>
>>>>>> https://github.com/stefwalter/systemd/commits/polkit-systemd1
>>>
>>> Hmm, yuck. There's a security issue here... Reading the capabilities
>>> from the sender on dbus1 is racy, since we have to read it from
>>> /proc/$PID/stat and don't get it sent along with the message, like we do
>>> on kdbus. A rogue client could send a message, quickly invoke some suid
>>> binary, and we'd consider the client trusted.
>>>
>>> Now for the low-level implementation of the vtable bit we are actually
>>> smart, and check by UID on dbus1, and by cap on kdbus, in order to avoid
>>> the vulnerability.
>>>
>>> Hmm, now I wonder how to best handle this for cases like this, we
>>> probably need some generic way how clients can make this decision in an
>>> always safe way...
>>>
>>> I need to think more about this...
>>
>> By the way, there's some similar problematic code in the modified
>> KillUnit() method implementation ... changed from specifying the
>> CAP_KILL in the vtable, and now it does a manual check.
>>
>>> Patch set looks great otherwise. I'll come up with something for the
>>> security issue, then adapt your patch, and merge it.
>>
>> I haven't tested the updated branch at all :) So it may go boom...
> 
> I have now pushed this, after reworking this on top some major changes
> to bus_verify_polkit(), which avoids having to pass the original
> callbacks through to the function that ultimately does the verification.
> 
> While merging I also made another change, you are probably not going to
> like: I turned of the interactivity for the polkit checks. Interactivity
> needs to be optional, and it currently is for all out polkit-enabled bus
> methods. And we should do the same for the PID 1 offered methods.

Ugh.

> Now, of course, we should open this up for inetractive (after all,
> that's what polkit is good for), but we probably need a new set of
> methods for that, which take the original arguments but also take a
> boolean argument to enable ineractivity. Hence, we probably should have
> StartUnit2() in addition to StartUnit().

That seems ugly. I think we should either:

 * Have a method which we can invoke to make a client opt into
   interactive polkit prompting for any invoked method.

 * Version all the org.freedesktop.systemd1.Manager to
   org.freedesktop.systemd1.Manager2 or something like that and support
   both interfaces.

Cheers,

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

Re: [systemd-devel] Work on adding polkit support to systemd1

[Stef Walter]

On 15.08.2014 18:56, Lennart Poettering wrote:
> On Fri, 15.08.14 18:25, Stef Walter (st...@redhat.com) wrote:
> 
>>
>> On 13.08.2014 20:27, Lennart Poettering wrote:
>>> On Wed, 06.08.14 13:23, Stef Walter (st...@redhat.com) wrote:
>>>
>>>> I've done initial work on adding polkit support to systemd1 DBus
>>>> methods. You can see it here:
>>
>> Thanks for the review. Worked on this a bit more.
>>
>> I might drop off the face of the earth for a couple weeks. In case I do,
>> I thought I'd update my public branch. But if I'm around, I'll test and
>> prepare a patch set early next week.
>>
>>>> https://github.com/stefwalter/systemd/commits/polkit-systemd1
> 
> Hmm, yuck. There's a security issue here... Reading the capabilities
> from the sender on dbus1 is racy, since we have to read it from
> /proc/$PID/stat and don't get it sent along with the message, like we do
> on kdbus. A rogue client could send a message, quickly invoke some suid
> binary, and we'd consider the client trusted.
> 
> Now for the low-level implementation of the vtable bit we are actually
> smart, and check by UID on dbus1, and by cap on kdbus, in order to avoid
> the vulnerability.
> 
> Hmm, now I wonder how to best handle this for cases like this, we
> probably need some generic way how clients can make this decision in an
> always safe way...
> 
> I need to think more about this...

By the way, there's some similar problematic code in the modified
KillUnit() method implementation ... changed from specifying the
CAP_KILL in the vtable, and now it does a manual check.

> Patch set looks great otherwise. I'll come up with something for the
> security issue, then adapt your patch, and merge it.

I haven't tested the updated branch at all :) So it may go boom...

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

Re: [systemd-devel] Work on adding polkit support to systemd1

[Stef Walter]

On 13.08.2014 20:27, Lennart Poettering wrote:
> On Wed, 06.08.14 13:23, Stef Walter (st...@redhat.com) wrote:
> 
>> I've done initial work on adding polkit support to systemd1 DBus
>> methods. You can see it here:

Thanks for the review. Worked on this a bit more.

I might drop off the face of the earth for a couple weeks. In case I do,
I thought I'd update my public branch. But if I'm around, I'll test and
prepare a patch set early next week.

>> https://github.com/stefwalter/systemd/commits/polkit-systemd1

Updated this branch ^^



>> The way that each callback in sd-bus has to handle verification seems a
>> bit risky to me. So I've only opened up the specific interfaces I
>> touched in the DBus policy file.

Your comments below address what I was worried about here ^^

> Regarding the fourth: please don't bind any checks against the UID,
> check for CAP_SYS_ADMIN instead, we make it equally easy.

Done.

> Why is verify_root_sync() invoked that often? I mean, for these cases
> the dbus1 policy should not grant access anyway, so we don't really need
> to check for permissions here again. I'd really prefer if on dbus1 would
> use the dbus1 policy for as much access control work as useful, and only
> do it on our own if we really need to.

Done.

> reload (and probably also reexecute) should probably hook into polkit
> too, with a new action? it sounds useful enough for people to invoke it
> frequently.

New action is called: org.freedesktop.systemd1.reload-daemon

> Note that on kdbus access control works differently than on dbus1: it's
> the client's responsibility to implement access control. To make this
> easy our sd-bus library actually allows encoding in the method vtable
> which calls are accessible for unpriviliged processes. That's what the
> SD_BUS_VTABLE_UNPRIVILEGED flag in the object vtables is for (grep for
> it). The flag (or its absence) has no effect on dbus1 daemons at all,
> and only matters for kdbus. To make sure your changes also work
> correctly and as intended on kdbus you need to add the flag to all
> methods that you are now opening up via polkit. Because otherwise method
> calls won't even get that far.
> 
> Or in other words: everything that is opened up in the dbus1 policy also
> needs to be opened up with SD_BUS_VTABLE_UNPRIVILIGED in the object
> vtables...

Makes sense ... but out of interest, why don't you just rely on this for
dbus1 as well? It seems that maintaining these two distinct access
control methods is risky.

> Sometiems you added spurious newlines to the patches, please don't.

Removed a couple extra newlines. I hope I found them all.

> I'd prefer if the dbus1 policy would precisely list the method calls
> that are now opened up...

Done.

One other thing is that it seems like the ofs.Manager.LoadUnit() DBus
method call is wide open for anyone to call. Is this intentional? I
don't know all the implications, but wanted to highlight it.

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

Re: [systemd-devel] Work on adding polkit support to systemd1

[Stef Walter]

On 06.08.2014 14:23, Colin Guthrie wrote:
> Stef Walter wrote on 06/08/14 12:23:
>> I've done initial work on adding polkit support to systemd1 DBus
>> methods.
> 
> Hmmm, I thought this was deliberately not included as it meant a
> circular dep on polkit when talking to the system that's used to start
> up polkitd itself... 

We were discussing this in Strasbourg. Lennart can probably summarize
better than I can. But my understanding is that these circular
dependency issues have been resolved.

> what happens if you try to talk to systemd1
> interface during early boot before polkitd has started (and before a dep
> that's needed by it) has started?

I think it falls back on just allowing uid zero. But would be good to
double check.

> I thought the main reason for logind to essentially proxy the
> Power/Reboot related stuff was such that polkit support could be added
> there outside of systemd1 itself and thus not have any circular dep
> problems.

FWIW, we don't involve polkit on on Power/Reboot and similar
of.systemd1.Manager method calls. General purpose callers should
continue to go through logind and/or the shutdown command.

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

[systemd-devel] Work on adding polkit support to systemd1

[Stef Walter]

I've done initial work on adding polkit support to systemd1 DBus
methods. You can see it here:

https://github.com/stefwalter/systemd/commits/polkit-systemd1

Basic rules:

 * Read access for everyone

 * Methods that modifies running unit state is controlled by a polkit
   action: org.freedesktop.systemd1.manage-units

 * Methods that modifies unit state files is controlled by a polkit
   action: org.freedesktop.systemd1.manage-unit-files

 * Many methods are only callable by root callers, like: Poweroff()
   Kexec() etc...

 * Job.Cancel() and Manager.CancelJob() are callable by the caller(s)
   that started the job.

 * Setting properties is only possible by root callers.

The way that each callback in sd-bus has to handle verification seems a
bit risky to me. So I've only opened up the specific interfaces I
touched in the DBus policy file.

Eventually the DBus policy file would go away, but hopefully sd-bus will
have a less risky way of verifying callers at that point.

I need to work on testing this. Will send a patch set when I'm done.

I'd be happy to add documentation here when we're done:

http://www.freedesktop.org/wiki/Software/systemd/dbus/

Cheers,

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

Re: [systemd-devel] Polkit and systemd D-Bus API

[Stef Walter]

On 15.07.2014 15:46, Jan Safranek wrote:
> On 07/15/2014 03:38 PM, Stef Walter wrote:
>> Not sure about:
>>
>>  * Halt(), PowerOff(), Reboot()
> 
> OpenLMI is interested in these. They are already covered by logind,
> which is integrated with polkit just fine. Look for actions like
> org.freedesktop.login1.reboot, reboot-multiple-sessions etc. in
> org.freedesktop.login1.policy.

Right. That's why I wasn't sure about them in the systemd D-Bus API.
Those seem like the low level implementations that we wouldn't call
directly, and we would use the stuff in logind instead.

Stef

-- 

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

Re: [systemd-devel] Polkit and systemd D-Bus API

[Stef Walter]

On 15.07.2014 15:15, Lennart Poettering wrote:
> On Tue, 15.07.14 13:35, Stef Walter (s...@thewalter.net) wrote:
> 
>> Cockpit, OpenLMI, and others want to use the systemd D-Bus API to manage
>> system services/sockets etc. In addition we use polkit to authorize
>> users and allow people to escalate privileges as needed.
>>
>> It seems that the D-Bus API of systemd doesn't support polkit:
>>
>> http://www.freedesktop.org/wiki/Software/systemd/dbus/
>>
>> So currently only root users can call this D-Bus API.
>>
>> Is the concept here that we write our own wrapper daemon (something like
>> systemd-polkit-verifyd) that listens on a different bus name and
>> authorizes with polkit before forwarding messages to systemd?
> 
> Previously our hook up with PK was awful, and could cause deadlocks when
> done from PID 1, which would then be both the process managing polkitd
> and its client -- which is why I never did polkit support for PID 1
> calls, but only for the other daemons. But this has been fixed since
> then, the polkit queries are now fully asynchronous, and we should
> probably open this up via polkit.
> 
> Which bus calls precisely are you interested in?

Since Cockpit has a pretty comprehensive UI for systemd units, it'd be
easier to list the DBus calls we're not interested in. But here goes,
off the top of my head:

 * All of the *Unit() calls and Unit object methods/properties
 * All of the *Job() calls
 * Subscribe()/Unsubscribe()
 * SetUnitProperties()
 * SetDefaultTarget()
 * StartTransientUnit()
 * ResetFailed()
 * readable properties
 * signals...

Not sure about:

 * Halt(), PowerOff(), Reboot()
 * *UnitFiles()

Not interested:

 * Reexecute(), Kexec()
 * SwitchRoot()
 * *Snapshot()

Also, usually most properties are be readable by unpriveleged users. Are
there any in systemd where this wouldn't be the case?

Stef

-- 

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

[systemd-devel] Polkit and systemd D-Bus API

[Stef Walter]

Cockpit, OpenLMI, and others want to use the systemd D-Bus API to manage
system services/sockets etc. In addition we use polkit to authorize
users and allow people to escalate privileges as needed.

It seems that the D-Bus API of systemd doesn't support polkit:

http://www.freedesktop.org/wiki/Software/systemd/dbus/

So currently only root users can call this D-Bus API.

Is the concept here that we write our own wrapper daemon (something like
systemd-polkit-verifyd) that listens on a different bus name and
authorizes with polkit before forwarding messages to systemd?

Cheers,

Stef

-- 

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

Re: [systemd-devel] [PATCH] cgroup: After MemmoryAccounting=yes running scope has no memusage

[Stef Walter]

On 09.04.2014 23:45, Lennart Poettering wrote:
> On Tue, 08.04.14 12:11, Stef Walter (s...@thewalter.net) wrote:
> 
>> Setting the 'MemoryAccounting' unit property to true, puts the
>> unit into the right cgroup but does the memory.usage_in_bytes
>> does not reflect the pages already allocated to the processes
>> in that cgroup.
>>
>> This is because the memory.move_charge_at_immigrate needs to be
>> set before migrating processes to the new cgroup memory
>> controller path:
>>
>> https://www.kernel.org/doc/Documentation/cgroups/memory.txt
>>
>> The attached path sets the memory.move_charge_at_immigrate to
>> 0x01 | 0x02 before migrating processes to a new memory cgroup.
> 
> To keep the list posted about this: we talked to the cgroup kernel guys
> about this and while it appears like the right thing to do this the
> kernel logic behind the option doesn't work correctly, and hence we
> shouldn't do this for now. And it appears likely that when the kernel
> fixes the behaviour it will be turned on by default anyway, without
> involving userspace.
> 
> Stef, is that a big problem for you? Not sure what else we can do about
> this for now though...

Yeah, this prevents us from displaying the amount of memory used by a
unit (or container) without first restarting it :S

But you can't gold plate a turd... So we probably have to expose the
limitations of the underlying stuff rather than work around them.

Stef

-- 

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

[systemd-devel] [PATCH] cgroup: After MemmoryAccounting=yes running scope has no memusage

[Stef Walter]

Setting the 'MemoryAccounting' unit property to true, puts the
unit into the right cgroup but does the memory.usage_in_bytes
does not reflect the pages already allocated to the processes
in that cgroup.

This is because the memory.move_charge_at_immigrate needs to be
set before migrating processes to the new cgroup memory
controller path:

https://www.kernel.org/doc/Documentation/cgroups/memory.txt

The attached path sets the memory.move_charge_at_immigrate to
0x01 | 0x02 before migrating processes to a new memory cgroup.
---
 src/core/cgroup.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/src/core/cgroup.c b/src/core/cgroup.c
index 3dd4c91..fcdbb07 100644
--- a/src/core/cgroup.c
+++ b/src/core/cgroup.c
@@ -26,6 +26,7 @@
 #include "special.h"
 #include "cgroup-util.h"
 #include "cgroup.h"
+#include "fileio.h"
 
 void cgroup_context_init(CGroupContext *c) {
 assert(c);
@@ -567,6 +568,8 @@ static const char *migrate_callback(CGroupControllerMask 
mask, void *userdata) {
 
 static int unit_create_cgroups(Unit *u, CGroupControllerMask mask) {
 _cleanup_free_ char *path = NULL;
+_cleanup_free_ char *fs = NULL;
+char c[DECIMAL_STR_MAX(pid_t) + 2];
 int r;
 
 assert(u);
@@ -596,6 +599,16 @@ static int unit_create_cgroups(Unit *u, 
CGroupControllerMask mask) {
 u->cgroup_realized = true;
 u->cgroup_realized_mask = mask;
 
+/* Before migrating actually turn memory migration on */
+if (mask & CGROUP_MEMORY) {
+snprintf(c, sizeof(c), "%d\n", 3);
+r = cg_get_path_and_check("memory", u->cgroup_path, 
"memory.move_charge_at_immigrate", &fs);
+if (r >= 0)
+r = write_string_file(fs, c);
+if (r < 0)
+log_error("Failed to set 
memory.move_change_at_immigrate on %s: %s", fs, strerror(-r));
+}
+
 /* Then, possibly move things over */
 r = cg_migrate_everywhere(u->manager->cgroup_supported, 
u->cgroup_path, u->cgroup_path, migrate_callback, u);
 if (r < 0)
-- 
1.8.5.3

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

[systemd-devel] [PATCH] autogen: Allow running autogen from a builddir != srcdir

[Stef Walter]

While the configure correctly supports being run outside of
the top source directory by default, it's nice if autogen.sh
does too:

 $ git clone git://anongit.freedesktop.org/systemd/systemd
 $ cd systemd
 $ mkdir $(uname -m)
 $ cd $(uname -m)
 $ ../autogen.sh a
 $ make
---
 autogen.sh | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/autogen.sh b/autogen.sh
index 20f013a..9b4781c 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -17,6 +17,10 @@
 
 set -e
 
+oldpwd=$(pwd)
+topdir=$(dirname $0)
+cd $topdir
+
 if [ -f .git/hooks/pre-commit.sample ] && [ ! -f .git/hooks/pre-commit ]; then
 # This part is allowed to fail
 cp -p .git/hooks/pre-commit.sample .git/hooks/pre-commit && \
@@ -53,20 +57,22 @@ args="$args \
 "
 fi
 
+cd $oldpwd
+
 if [ "x$1" = "xc" ]; then
-./configure CFLAGS='-g -O0 -ftrapv' --enable-compat-libs 
--enable-kdbus $args
+$topdir/configure CFLAGS='-g -O0 -ftrapv' --enable-compat-libs 
--enable-kdbus $args
 make clean
 elif [ "x$1" = "xg" ]; then
-./configure CFLAGS='-g -Og -ftrapv' --enable-compat-libs 
--enable-kdbus $args
+$topdir/configure CFLAGS='-g -Og -ftrapv' --enable-compat-libs 
--enable-kdbus $args
 make clean
 elif [ "x$1" = "xa" ]; then
-./configure CFLAGS='-g -O0 -Wsuggest-attribute=pure 
-Wsuggest-attribute=const -ftrapv' --enable-compat-libs --enable-kdbus $args
+$topdir/configure CFLAGS='-g -O0 -Wsuggest-attribute=pure 
-Wsuggest-attribute=const -ftrapv' --enable-compat-libs --enable-kdbus $args
 make clean
 elif [ "x$1" = "xl" ]; then
-./configure CC=clang CFLAGS='-g -O0 -ftrapv -Wno-gnu' 
--enable-compat-libs --enable-kdbus $args
+$topdir/configure CC=clang CFLAGS='-g -O0 -ftrapv -Wno-gnu' 
--enable-compat-libs --enable-kdbus $args
 make clean
 elif [ "x$1" = "xs" ]; then
-scan-build ./configure CFLAGS='-g -O0 -ftrapv' --enable-compat-libs 
--enable-kdbus $args
+scan-build $topdir/configure CFLAGS='-g -O0 -ftrapv' 
--enable-compat-libs --enable-kdbus $args
 scan-build make
 else
 echo
@@ -74,6 +80,6 @@ else
 echo "Initialized build system. For a common configuration please run:"
 echo ""
 echo
-echo "./configure CFLAGS='-g -O0 -ftrapv' --enable-compat-libs 
--enable-kdbus $args"
+echo "$topdir/configure CFLAGS='-g -O0 -ftrapv' --enable-compat-libs 
--enable-kdbus $args"
 echo
 fi
-- 
1.8.5.3

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

[systemd-devel] [PATCH] hostnamed: Fix the way that static and transient host names interact

[Stef Walter]

It is almost always incorrect to allow DHCP or other sources of
transient host names to override an explicitly configured static host
name.

This commit changes things so that if a static host name is set, this
will override the transient host name (eg: provided via DHCP). Transient
host names can still be used to provide host names for machines that have
not been explicitly configured with a static host name.

The exception to this rule is if the static host name is set to
"localhost" or matches "localhost.*". In those cases we act as if no
static host name has been explicitly set.

As discussed elsewhere, systemd may want to have an fd based ownership
of the transient name. That part is not included in this commit.
---
 man/hostnamectl.xml  |  8 +++-
 src/hostname/hostnamed.c | 36 +++-
 2 files changed, 34 insertions(+), 10 deletions(-)

diff --git a/man/hostnamectl.xml b/man/hostnamectl.xml
index 4bc05f5..80e8cde 100644
--- a/man/hostnamectl.xml
+++ b/man/hostnamectl.xml
@@ -68,11 +68,9 @@
 (e.g. "Lennart's Laptop"), the static hostname which
 is used to initialize the kernel hostname at boot
 (e.g. "lennarts-laptop"), and the transient hostname
-which might be assigned temporarily due to network
-configuration and might revert back to the static
-hostname if network connectivity is lost and is only
-temporarily written to the kernel hostname
-(e.g. "dhcp-47-11").
+which is a default received from network configuration.
+If a static hostname is set, and is valid (something other
+than localhost) then the transient hostname is not used.
 
 Note that the pretty hostname has little
 restrictions on the characters used, while the static
diff --git a/src/hostname/hostnamed.c b/src/hostname/hostnamed.c
index e57891b..5174fa8 100644
--- a/src/hostname/hostnamed.c
+++ b/src/hostname/hostnamed.c
@@ -228,16 +228,36 @@ static char* context_fallback_icon_name(Context *c) {
 return strdup("computer");
 }
 
-static int context_write_data_hostname(Context *c) {
+static bool hostname_is_useful(const char *hn) {
+return !isempty(hn) && !streq(hn, "localhost") &&
+   !startswith(hn, "localhost.");
+}
+
+static int context_update_kernel_hostname(Context *c) {
+const char *static_hn;
 const char *hn;
 
 assert(c);
 
-if (isempty(c->data[PROP_HOSTNAME]))
-hn = "localhost";
-else
+static_hn = c->data[PROP_STATIC_HOSTNAME];
+
+/* /etc/hostname with something other than "localhost"
+ * has the highest preference ... */
+if (hostname_is_useful(static_hn))
+hn = static_hn;
+
+/* ... the transient host name, (ie: DHCP) comes next ...*/
+else if (!isempty(c->data[PROP_HOSTNAME]))
 hn = c->data[PROP_HOSTNAME];
 
+/* ... fallback to static "localhost.*" ignored above ... */
+else if (!isempty(static_hn))
+hn = static_hn;
+
+/* ... and the ultimate fallback */
+else
+hn = "localhost";
+
 if (sethostname(hn, strlen(hn)) < 0)
 return -errno;
 
@@ -389,7 +409,7 @@ static int method_set_hostname(sd_bus *bus, sd_bus_message 
*m, void *userdata, s
 free(c->data[PROP_HOSTNAME]);
 c->data[PROP_HOSTNAME] = h;
 
-r = context_write_data_hostname(c);
+r = context_update_kernel_hostname(c);
 if (r < 0) {
 log_error("Failed to set host name: %s", strerror(-r));
 return sd_bus_error_set_errnof(error, r, "Failed to set 
hostname: %s", strerror(-r));
@@ -441,6 +461,12 @@ static int method_set_static_hostname(sd_bus *bus, 
sd_bus_message *m, void *user
 c->data[PROP_STATIC_HOSTNAME] = h;
 }
 
+r = context_update_kernel_hostname(c);
+if (r < 0) {
+log_error("Failed to set host name: %s", strerror(-r));
+return sd_bus_error_set_errnof(error, r, "Failed to set 
hostname: %s", strerror(-r));
+}
+
 r = context_write_data_static_hostname(c);
 if (r < 0) {
 log_error("Failed to write static host name: %s", 
strerror(-r));
-- 
1.8.5.3

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

Re: [systemd-devel] Have 'session' keyrings per service

[Stef Walter]

On 10.08.2013 07:22, Stef Walter wrote:
> On 09.08.2013 17:44, Lennart Poettering wrote:
>> On Thu, 08.08.13 12:15, Stef Walter (st...@redhat.com) wrote:
>>
>>> Hey guys. I'm trying to figure out details for:
>>>
>>> http://www.freedesktop.org/wiki/Specifications/login-unlock/
>>>
>>> Lennart we talked about this briefly in Brno ... basically the concept
>>> is that when systemd does cryptsetup, it'll stash away the password it
>>> successfully used in the kernel keyring, and then the PAM stack in GDM
>>> will use it to try and log the user in.
>>>
>>> One thing we should work out is how to avoid having any uid 0 process
>>> accessing that password at will. By:
>>>
>>>  1. Obviously, a kernel keyring timeout.
>>>  2. Putting it in a keyring that only certain services have access to.
>>
>> Hmm, well, what's the point of this part? I mean, on Unix security is
>> either bound to UIDs/GIDs, or to MAC labels, we shouldn't attempt to
>> introduce half-assed security checks beyond that... 
> 
> Fair point. That makes some sense...
> 
> I mean, ptrace()
>> allows you to impersonate anybody you like if that someone has the same
>> UID you have, so what's the point of doing per-session or per-service
>> access control?
>>
>> I'd just stick this into the keyring of UID 0 with a timeout of 2min or
>> so, and that'd be it.
> 
> ... but your conclusion is wrong. It's pretty obvious that a UID 0
> process like openvpn shouldn't be able to get at the user's disk
> encryption password (even if it is only for 2 minutes after boot).
> 
> So we should be relying on MAC at the very least.
> 
> But perhaps we should be hashing the password before storage in the
> kernel keyring. Hashing with the various forms of crypt + a strong
> pbkdf2 hash actually covers the various ways the password would be used.

Actually, as I sent this, I realized it doesn't cover the 'multiple
disks encrypted with same password' use case.

Stef

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

Re: [systemd-devel] Have 'session' keyrings per service

[Stef Walter]

On 09.08.2013 17:44, Lennart Poettering wrote:
> On Thu, 08.08.13 12:15, Stef Walter (st...@redhat.com) wrote:
> 
>> Hey guys. I'm trying to figure out details for:
>>
>> http://www.freedesktop.org/wiki/Specifications/login-unlock/
>>
>> Lennart we talked about this briefly in Brno ... basically the concept
>> is that when systemd does cryptsetup, it'll stash away the password it
>> successfully used in the kernel keyring, and then the PAM stack in GDM
>> will use it to try and log the user in.
>>
>> One thing we should work out is how to avoid having any uid 0 process
>> accessing that password at will. By:
>>
>>  1. Obviously, a kernel keyring timeout.
>>  2. Putting it in a keyring that only certain services have access to.
> 
> Hmm, well, what's the point of this part? I mean, on Unix security is
> either bound to UIDs/GIDs, or to MAC labels, we shouldn't attempt to
> introduce half-assed security checks beyond that... 

Fair point. That makes some sense...

I mean, ptrace()
> allows you to impersonate anybody you like if that someone has the same
> UID you have, so what's the point of doing per-session or per-service
> access control?
> 
> I'd just stick this into the keyring of UID 0 with a timeout of 2min or
> so, and that'd be it.

... but your conclusion is wrong. It's pretty obvious that a UID 0
process like openvpn shouldn't be able to get at the user's disk
encryption password (even if it is only for 2 minutes after boot).

So we should be relying on MAC at the very least.

But perhaps we should be hashing the password before storage in the
kernel keyring. Hashing with the various forms of crypt + a strong
pbkdf2 hash actually covers the various ways the password would be used.

Remember the goal we're trying to acheive. If cryptsetup and gdm (well
its pam stack) were running at the same time we'd set this up so it just
passed the password over directly, and not stored somewhere all UID 0
processes could access it (ie: essentially broadcast). However there is
a temporal gap between the two, and thus the kernel keyring becomes a
transfer mechanism.

With something like the disk encryption password, it's worth adding
another layer that needs to be broken before the raw password is exposed.

Will research pre-hashing further.

Cheers,

Stef

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

[systemd-devel] Have 'session' keyrings per service

[Stef Walter]

Hey guys. I'm trying to figure out details for:

http://www.freedesktop.org/wiki/Specifications/login-unlock/

Lennart we talked about this briefly in Brno ... basically the concept
is that when systemd does cryptsetup, it'll stash away the password it
successfully used in the kernel keyring, and then the PAM stack in GDM
will use it to try and log the user in.

One thing we should work out is how to avoid having any uid 0 process
accessing that password at will. By:

 1. Obviously, a kernel keyring timeout.
 2. Putting it in a keyring that only certain services have access to.

The second is why I'm writing...

I'm thinking about the idea of defining a named session keyring per
systemd unit (kernel 'session keyrings' have nothing to do with user
login sessions, overloaded term, :S ).

On its own this makes a lot of sense, since we essentially make a
per-cgroup keyring for services, which becomes really useful.

Then also have the ability to in a .service file to define additional
named keyrings that are searchable for the service.

So perhaps cryptsetup would put the password in its own named keyring,
and then gdm.service would have:

[Service]
Keyrings=@cryptsetup

Which tells systemd to link the cryptsetup keyring into the gdm
(session) keyring. That makes gdm be able to find and use keys in the
cryptsetup keyring.

I think I've figured out a way to implement the above. But anyone
already thought about this? Other use cases?

Cheers,

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