Re: [systemd-devel] Race condition between udev rules and hwdb

[Mantas Mikulėnas]

On Tue, Feb 6, 2018 at 1:21 AM, Peter Hutterer 
wrote:

> On Mon, Feb 05, 2018 at 11:51:30AM +0200, Mantas Mikulėnas wrote:
> > On Mon, Feb 5, 2018 at 8:02 AM, Peter Hutterer  >
> > wrote:
> >
> > > Hi all,
> > >
> > > I think there is some race conditions between the udev rules and the
> hwdb
> > > and I cannot rely that udev rules are applied consistently on a device.
> > >
> > > For reference, after building libinput run
> > >   sudo ./build/libinput-test-suite-runner --filter-test=lid_update_hw_
> > > on_key_multiple_keyboards
> > > run it repeatedly and at some point it will fail.
> > >
> > > The source of the issue is the udev properties for the test device
> > > *sometimes* get overwritten by the hwdb value of a rule with a lower
> > > lexical
> > > ordering. In other words: 90-something.hwdb+rules overwrites
> > > 99-myrule.rules, that shouldn't happen (or at least not randomly).
> > >
> > > For more detail, the relevant parts are:
> > >
> > > 90-foo.hwdb entry with a dmi match that assigns a property
> > >
> > > libinput:name:*Lid Switch*:dmi:*:ct9:*
> > >  LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=reliable
> > >
> > > and the matching 90-foo.rules:
> > > KERNELS=="input*", \
> > >   IMPORT{builtin}="hwdb 'libinput:name:$attr{name}:$
> > > attr{[dmi/id]modalias}'"
> > >
> > > This assigns 'reliable' to the device.
> > >
> > > I also have per-device udev rules, 92-foo.rules, in this case:
> > >
> > > ATTRS{name}=="litest Lid Switch Surface3*", \
> > > ENV{ID_INPUT_SWITCH}="1", \
> > > ENV{LIBINPUT_ATTR_LID_SWITCH_RELIABILITY}="write_open"
> > >
> > > This overwrites 'reliable' with 'write_open'.
> > >
> > > On test-runner start, we install all the udev rules and hwdb files, run
> > > hwdb
> > > --update and then start the tests.
> > >
> > > In *most* cases, 'write_open' is correctly assigned to the device. In
> the
> > > failure cases, 'reliable' is assigned. Nothing changes in the udevadm
> test
> > > output and I've verified that the order appears to change, in the
> failure
> > > cases the 92-foo.rules applies before the hwdb overwrites it:
> > >
> > > ATTRS{name}=="litest Lid Switch Surface3*",
> > > ENV{ID_INPUT_SWITCH}="1",
> > > ENV{BONGO}="litest",
> > > ENV{LIBINPUT_ATTR_LID_SWITCH_RELIABILITY}="write_open"
> > >
> > > ATTRS{name}=="litest Lid Switch Surface3*",
> > > ENV{FIRSTVAL}="$env{LIBINPUT_ATTR_LID_SWITCH_RELIABILITY}"
> > >
> > > Running with this udev rule shows that FIRSTVAL is write_open but the
> real
> > > property is 'reliable'.
> > >
> > > This happens anywhere between 1 out of 3 and 1 out of 50, though it
> seems
> > > to
> > > be more common when creating/removing uinput devices like crazy.
> >
> >
> > Here's a wild guess...
> >
> > I wonder if the race condition is in ATTRS{}; attributes are not cached
> but
> > read directly from sysfs, and for ATTRS udev has to go upwards the entire
> > /sys hierarchy – for each and every rule, I believe.
> >
> > So it could be that some rules do not match because by that time the
> device
> > has already disappeared. What happens if you change the rules to rely
> > entirely on ENV{} matches?
>
> Thanks for the tip, unfortunately I couldn't verify it. I tried that
> yesterday but it's... difficult. Matching on ENV{NAME} turned out to be
> more
> volatile than I expected [1] but the main issue I have here is that NAME is
> set on the parent input device, not on the evdev node where everything else
> is set. There is no ENVS support to search up from the device, so I'm not
> sure I could coerce the rules and hwdb matching into the required
> hierarchy.
>

Yeah, after some sleep I realized I'm probably *way* off.

(That said, there is IMPORT{parent}="fooenv".)

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

Re: [systemd-devel] Race condition between udev rules and hwdb

[Peter Hutterer]

On Mon, Feb 05, 2018 at 11:51:30AM +0200, Mantas Mikulėnas wrote:
> On Mon, Feb 5, 2018 at 8:02 AM, Peter Hutterer 
> wrote:
> 
> > Hi all,
> >
> > I think there is some race conditions between the udev rules and the hwdb
> > and I cannot rely that udev rules are applied consistently on a device.
> >
> > For reference, after building libinput run
> >   sudo ./build/libinput-test-suite-runner --filter-test=lid_update_hw_
> > on_key_multiple_keyboards
> > run it repeatedly and at some point it will fail.
> >
> > The source of the issue is the udev properties for the test device
> > *sometimes* get overwritten by the hwdb value of a rule with a lower
> > lexical
> > ordering. In other words: 90-something.hwdb+rules overwrites
> > 99-myrule.rules, that shouldn't happen (or at least not randomly).
> >
> > For more detail, the relevant parts are:
> >
> > 90-foo.hwdb entry with a dmi match that assigns a property
> >
> > libinput:name:*Lid Switch*:dmi:*:ct9:*
> >  LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=reliable
> >
> > and the matching 90-foo.rules:
> > KERNELS=="input*", \
> >   IMPORT{builtin}="hwdb 'libinput:name:$attr{name}:$
> > attr{[dmi/id]modalias}'"
> >
> > This assigns 'reliable' to the device.
> >
> > I also have per-device udev rules, 92-foo.rules, in this case:
> >
> > ATTRS{name}=="litest Lid Switch Surface3*", \
> > ENV{ID_INPUT_SWITCH}="1", \
> > ENV{LIBINPUT_ATTR_LID_SWITCH_RELIABILITY}="write_open"
> >
> > This overwrites 'reliable' with 'write_open'.
> >
> > On test-runner start, we install all the udev rules and hwdb files, run
> > hwdb
> > --update and then start the tests.
> >
> > In *most* cases, 'write_open' is correctly assigned to the device. In the
> > failure cases, 'reliable' is assigned. Nothing changes in the udevadm test
> > output and I've verified that the order appears to change, in the failure
> > cases the 92-foo.rules applies before the hwdb overwrites it:
> >
> > ATTRS{name}=="litest Lid Switch Surface3*",
> > ENV{ID_INPUT_SWITCH}="1",
> > ENV{BONGO}="litest",
> > ENV{LIBINPUT_ATTR_LID_SWITCH_RELIABILITY}="write_open"
> >
> > ATTRS{name}=="litest Lid Switch Surface3*",
> > ENV{FIRSTVAL}="$env{LIBINPUT_ATTR_LID_SWITCH_RELIABILITY}"
> >
> > Running with this udev rule shows that FIRSTVAL is write_open but the real
> > property is 'reliable'.
> >
> > This happens anywhere between 1 out of 3 and 1 out of 50, though it seems
> > to
> > be more common when creating/removing uinput devices like crazy.
> 
> 
> Here's a wild guess...
> 
> I wonder if the race condition is in ATTRS{}; attributes are not cached but
> read directly from sysfs, and for ATTRS udev has to go upwards the entire
> /sys hierarchy – for each and every rule, I believe.
> 
> So it could be that some rules do not match because by that time the device
> has already disappeared. What happens if you change the rules to rely
> entirely on ENV{} matches?

Thanks for the tip, unfortunately I couldn't verify it. I tried that
yesterday but it's... difficult. Matching on ENV{NAME} turned out to be more
volatile than I expected [1] but the main issue I have here is that NAME is
set on the parent input device, not on the evdev node where everything else
is set. There is no ENVS support to search up from the device, so I'm not
sure I could coerce the rules and hwdb matching into the required hierarchy.
Some of the match bits require the event node's detail, so I can't easily
assign the properties to the parent device.

That aside, I *know* that the devices aren't removed until I finished with
them, they're created in the same process as part of the test setup/tear
down. And after the uinput device is created, I even wait for udev's 'add'
event before passing control to libinput [2]. So in theory, there's no way
the device is being deleted before udev had time to set everything up.

Given they're a hierarchy too, what's the likelyhood that
/sys/.../input/input123 device isn't there when the
/sys/.../input/input123/event0 device shows up?

Cheers,
   Peter

[1] I think udev easily gets confused here because the name includes the
quotes so any rule has to either use * or use some magic I can't figure out
to work around that.
[2] https://github.com/wayland-project/libinput/blob/master/test/litest.c#L2732
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers

[Lennart Poettering]

On Mo, 05.02.18 10:21, Johannes Ernst (johannes.er...@gmail.com) wrote:

> >> It appears systemd-sysusers does not create home directories. On
> >> the other hand, it picks (largely unpredictable) UIDs from a
> >> range.
> >> 
> >> So I have to run systemd-sysusers, and after that, find the UID
> >> of the user and chown the home directory? Or is there the
> >> equivalent of the “useradd -m” flag somewhere that I’m just not
> >> seeing?
> > 
> > systemd-sysusers is, as the name suggests, really for _system_
> > users, and often those kinds of users don't have ordinary home
> > directories -- that is, ones the user can actually write to.
> 
> I agree with the “often” but not more :-)
> 
> > However, systemd-sysusers.service is ordered before
> > systemd-tmpfiles-setup.service at boot, so if you need to create a
> > system user's home directory and ensure its ownership is correct,
> > you could use a corresponding tmpfiles.d fragment to do so.
> 
> Hmm … tmpfiles.d, according to its man page, is for “the creation,
> cleaning and removal of volatile and temporary files and directories
> which usually reside in directories such as /run or /tmp.”. That
> doesn’t really seem to cover home directories that contain actual
> data.
> 
> Here’s my use case: Take a package for a daemon foo. The package
> contains a foo.service, and when foo runs, it is supposed to run in
> its own little place /var/lib/foo where it stores its data
> files. Because not everybody runs foo, it doesn’t make sense to pick
> a “fixed” UID like for more common daemons. Allocating a UID from a
> pool, like sysusers does, seems perfect. But how does the package
> ship /var/lib/foo? It can’t ship with owner foo because we don’t
> know what its UID is going to be. So the package, as part of its
> install script, needs to do something like:

My recommendation: simply use StateDirectory=foo in the service's unit
file (along with User=foo) to make things simpler and more robust. In
that case the directory is created automatically when the service is
started first, and chown()ed to the selected user. Note that this
works even if your service wants to drop privs on its own, because in
that case you can prefix its ExecStart= command line with "!", which
disables systemd's UID dropping code for that line. That way you can
safely declare a user in a service so that StateDirectory= has the
right ownership without this also implying systemd drops privs for
you.

Lennart

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

Re: [systemd-devel] systemd-sysusers

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 05, 2018 at 10:21:17AM -0800, Johannes Ernst wrote:
> 
> > On Feb 4, 2018, at 21:56, Michael Chapman  wrote:
> > 
> > On Mon, 5 Feb 2018, Johannes Ernst wrote:
> >> It appears systemd-sysusers does not create home directories. On the other 
> >> hand, it picks (largely unpredictable) UIDs from a range.
> >> 
> >> So I have to run systemd-sysusers, and after that, find the UID of the 
> >> user and chown the home directory? Or is there the equivalent of the 
> >> “useradd -m” flag somewhere that I’m just not seeing?
> > 
> > systemd-sysusers is, as the name suggests, really for _system_ users, and 
> > often those kinds of users don't have ordinary home directories -- that is, 
> > ones the user can actually write to.
> 
> I agree with the “often” but not more :-)
> 
> > However, systemd-sysusers.service is ordered before 
> > systemd-tmpfiles-setup.service at boot, so if you need to create a system 
> > user's home directory and ensure its ownership is correct, you could use a 
> > corresponding tmpfiles.d fragment to do so.
> 
> Hmm … tmpfiles.d, according to its man page, is for “the creation, cleaning 
> and removal of volatile and temporary files and directories which usually 
> reside in directories such as /run or /tmp.”. That doesn’t really seem to 
> cover home directories that contain actual data.
> 
> Here’s my use case: Take a package for a daemon foo. The package contains a 
> foo.service, and when foo runs, it is supposed to run in its own little place 
> /var/lib/foo where it stores its data files. Because not everybody runs foo, 
> it doesn’t make sense to pick a “fixed” UID like for more common daemons. 
> Allocating a UID from a pool, like sysusers does, seems perfect. But how does 
> the package ship /var/lib/foo? It can’t ship with owner foo because we don’t 
> know what its UID is going to be. So the package, as part of its install 
> script, needs to do something like:
> 
> systemd-sysusers
> [[ -d /var/lib/foo ]] && mkdir -m755 /var/lib/foo
> chown $(id -u foo):$(id -g foo) /var/lib/foo

# /usr/lib/tmpfiles.d/foo.conf
d /var/lib/foo 0755 foo foo -

(BTW, chown $(id -u foo):$(id -g foo) ... is the same as chown foo:foo ...).

Zbyszek

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

Re: [systemd-devel] systemd-sysusers

[Reindl Harald]

Am 05.02.2018 um 19:35 schrieb Johannes Ernst:

On Feb 5, 2018, at 10:31, Zbigniew Jędrzejewski-Szmek  wrote:





systemd-sysusers
[[ -d /var/lib/foo ]] && mkdir -m755 /var/lib/foo
chown $(id -u foo):$(id -g foo) /var/lib/foo


# /usr/lib/tmpfiles.d/foo.conf
d /var/lib/foo 0755 foo foo -

(BTW, chown $(id -u foo):$(id -g foo) ... is the same as chown foo:foo …).


Good point :-)

If so, the wording in man systemd-tmpfiles.d is still rather discouraging to 
people like me to do it this way because it very clearly talks about 
“temporary” files


because the stuff in /tmp and especially /run *is* temporary based on 
the nature of tmpfs

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

Re: [systemd-devel] systemd-sysusers

[Johannes Ernst]

> On Feb 5, 2018, at 10:31, Zbigniew Jędrzejewski-Szmek  
> wrote:



>> systemd-sysusers
>> [[ -d /var/lib/foo ]] && mkdir -m755 /var/lib/foo
>> chown $(id -u foo):$(id -g foo) /var/lib/foo
> 
> # /usr/lib/tmpfiles.d/foo.conf
> d /var/lib/foo 0755 foo foo -
> 
> (BTW, chown $(id -u foo):$(id -g foo) ... is the same as chown foo:foo …).

Good point :-)

If so, the wording in man systemd-tmpfiles.d is still rather discouraging to 
people like me to do it this way because it very clearly talks about 
“temporary” files.

Thanks,



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

Re: [systemd-devel] systemd-sysusers

[Johannes Ernst]

> On Feb 4, 2018, at 21:56, Michael Chapman  wrote:
> 
> On Mon, 5 Feb 2018, Johannes Ernst wrote:
>> It appears systemd-sysusers does not create home directories. On the other 
>> hand, it picks (largely unpredictable) UIDs from a range.
>> 
>> So I have to run systemd-sysusers, and after that, find the UID of the user 
>> and chown the home directory? Or is there the equivalent of the “useradd -m” 
>> flag somewhere that I’m just not seeing?
> 
> systemd-sysusers is, as the name suggests, really for _system_ users, and 
> often those kinds of users don't have ordinary home directories -- that is, 
> ones the user can actually write to.

I agree with the “often” but not more :-)

> However, systemd-sysusers.service is ordered before 
> systemd-tmpfiles-setup.service at boot, so if you need to create a system 
> user's home directory and ensure its ownership is correct, you could use a 
> corresponding tmpfiles.d fragment to do so.

Hmm … tmpfiles.d, according to its man page, is for “the creation, cleaning and 
removal of volatile and temporary files and directories which usually reside in 
directories such as /run or /tmp.”. That doesn’t really seem to cover home 
directories that contain actual data.

Here’s my use case: Take a package for a daemon foo. The package contains a 
foo.service, and when foo runs, it is supposed to run in its own little place 
/var/lib/foo where it stores its data files. Because not everybody runs foo, it 
doesn’t make sense to pick a “fixed” UID like for more common daemons. 
Allocating a UID from a pool, like sysusers does, seems perfect. But how does 
the package ship /var/lib/foo? It can’t ship with owner foo because we don’t 
know what its UID is going to be. So the package, as part of its install 
script, needs to do something like:

systemd-sysusers
[[ -d /var/lib/foo ]] && mkdir -m755 /var/lib/foo
chown $(id -u foo):$(id -g foo) /var/lib/foo

I’d rather prefer a flag (if not the default) in the .conf file saying “create 
directory if it does not exist”. Perhaps worth adding?

But thanks for confirming that I didn’t miss anything, and I indeed need to 
jump through this hoop.

Cheers,



Johannes.



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

Re: [systemd-devel] set-property does not work properly

[Lennart Poettering]

On Fr, 02.02.18 19:09, worz (w...@tuta.io) wrote:

Humm, your emails are really weirdly formatted. Generally, sending
HTML email to technical mailing lists is frowned upon, as replying is
very messy. We usually won't complain about this too much, but in this
case I have trouble getting good old mutt to make any sense of your
formatting, hence, please, next time please send text emails. Thank
you for understanding.

> Hello,It appears the situation with set-property is a bit awkward,
> quoting the man page for systemctlset-property NAME ASSIGNMENT...   
>        Set the specified unit properties at runtime where this is
> supported.           This allows changing configuration parameter
> properties such as           resource control settings at
> runtime. Not all properties may be           changed at runtime, but
> many resource control settings (primarily           those in
> systemd.resource-control(5)) may. The changes are applied         
>  instantly, and stored on disk for future boots, unless --runtime
> is           passed, in which case the settings only apply until the
> next reboot.           The syntax of the property assignment follows
> closely the syntax of           assignments in unit files.         
>    Example: systemctl set-property foobar.service CPUShares=777    
>        If the specified unit appears to be inactive, the changes
> will be only           stored on disk as described previously hence
> they will be effective           when the unit will be started.  but
> even when --runtime is not passed, and say user-1000.slice is
> active, and systemctl set-property user-1000.slice
> MemoryLimit=7G should apply it instantly, and store it on disk in
> /etc for future reboots, at
> /etc/systemd/system/user-1000.slice.d/50-MemoryLimit.conf. This is
> not the case, and the contradictory behaviour (wrt the
> documentation) is that the drop-in is made under
> /run/systemd/transient/user-1000.slice.d/ even when --runtime was
> not passed, hence the unit wont stick through reboots.  It was
> argued in https://github.com/systemd/systemd/issues/7106 that as
> purely transient objects, drop-ins generated shouldn't reside on
> disk for this slice, but for the user who does not know if systemctl
> is a D-Bus client for the Manager, it makes sense for the drop-in to
> be persistent. Can this be reconsidered, and if this is not
> possible, atleast a fix be accepted for the documentation to state
> otherwise?

I am not sure I follow, but note that logind generates the per-user
slices as transient units, and currently this means that all property
changes to it are transient too and won't hit the disk.

And yes, this is something we might want to reconsider, i.e. by
allowing non-transient property changes stored for transient
units. That's why issue #7106 remains open and is marked as RFE...

But yeah, we might want to document this too.

Lennart

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

Re: [systemd-devel] Why is systemd-run --scope synchronous?

[Jérémy Rosen]

I would understand the question as :

"why is the foreground/background concept linked to the concept of scope ?"

for most people --scope means "run in the background" which is only a 
side effect of what that command really does.


Maybe there is a need of some doc clarification, or get non-scope runs 
also be foreground and leave backgrounding to the shell...


Anyway, the first step is to understand why there is this difference of 
behaviour in the first place...



On 05/02/2018 14:59, Lennart Poettering wrote:

On Fr, 02.02.18 19:00, worz (w...@tuta.io) wrote:


Hello, I was wondering why systemd-run --scope needs to be
synchronous, it would be nice if someone could explain what happens
under the hood, and what prevents it from just putting the process
in the scope, and maybe just call the Abandon() method on the slice
object's org.freedesktop.systemd1.Scope interface, when for example
it is used in combination with --user, the scope is under
user@1000.service, so it should be cleaned up as soon as the service
manager goes away? Note that there's not a specific usecase to cover
here, I am just interested in knowing why it isn't the other way.

Hmm, I am not sure what you precisely mean by "synchronous" in this
context?

Is this about the bus calls being issued synchronously? We do that so
that at the time the user-specified command is executed we know for
sure that the resource limits and other things are in effect on it. If
we'd asynchronously register the scope and would already execute the
user's command, then these resource limits would only be applied
asynchronously, i.e. at some later point too, which is generally not
what is intended.

Or are you using the word "synchronous" in the context of foreground
vs. background? I.e. you want your process to be forked into the
background? That's actually done by default by systemd-run when you
don't use "--scope", where the executed process is moved into into the
background as a service.

Note that "systemd-run --scope" is little more than an
execve()-wrapper: if you want the whole thing to be running as a
shell managed background process, then suffix the line in "&" like you
would normally do too, when you don't use "systemd-run"...

But then again, I am not sure what you actually are looking for so
maybe my answers above completely miss the point...

Lennart



--
SMILE 

20 rue des Jardins
92600 Asnières-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.ro...@smile.fr 
phone +33141402967
url http://www.smile.eu

Twitter  Facebook 
 LinkedIn 
 Github 




Découvrez l’univers Smile, rendez-vous sur smile.eu 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Why is systemd-run --scope synchronous?

[Lennart Poettering]

On Fr, 02.02.18 19:00, worz (w...@tuta.io) wrote:

> Hello, I was wondering why systemd-run --scope needs to be
> synchronous, it would be nice if someone could explain what happens
> under the hood, and what prevents it from just putting the process
> in the scope, and maybe just call the Abandon() method on the slice
> object's org.freedesktop.systemd1.Scope interface, when for example
> it is used in combination with --user, the scope is under
> user@1000.service, so it should be cleaned up as soon as the service
> manager goes away? Note that there's not a specific usecase to cover
> here, I am just interested in knowing why it isn't the other way.

Hmm, I am not sure what you precisely mean by "synchronous" in this
context?

Is this about the bus calls being issued synchronously? We do that so
that at the time the user-specified command is executed we know for
sure that the resource limits and other things are in effect on it. If
we'd asynchronously register the scope and would already execute the
user's command, then these resource limits would only be applied
asynchronously, i.e. at some later point too, which is generally not
what is intended.

Or are you using the word "synchronous" in the context of foreground
vs. background? I.e. you want your process to be forked into the
background? That's actually done by default by systemd-run when you
don't use "--scope", where the executed process is moved into into the
background as a service.

Note that "systemd-run --scope" is little more than an
execve()-wrapper: if you want the whole thing to be running as a
shell managed background process, then suffix the line in "&" like you
would normally do too, when you don't use "systemd-run"...

But then again, I am not sure what you actually are looking for so
maybe my answers above completely miss the point...

Lennart

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

Re: [systemd-devel] hash context not closed.

[Stef Bon]

hi,

maybe good to know that libgcrypt provides a function which offers "all in one":

 void gcry_md_hash_buffer (int algo, void *digest, const void *buffer,
size_t length)

digest can be an array created earlier using the function gcry_md_get_algo_dlen.

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

Re: [systemd-devel] Race condition between udev rules and hwdb

[Mantas Mikulėnas]

On Mon, Feb 5, 2018 at 8:02 AM, Peter Hutterer 
wrote:

> Hi all,
>
> I think there is some race conditions between the udev rules and the hwdb
> and I cannot rely that udev rules are applied consistently on a device.
>
> For reference, after building libinput run
>   sudo ./build/libinput-test-suite-runner --filter-test=lid_update_hw_
> on_key_multiple_keyboards
> run it repeatedly and at some point it will fail.
>
> The source of the issue is the udev properties for the test device
> *sometimes* get overwritten by the hwdb value of a rule with a lower
> lexical
> ordering. In other words: 90-something.hwdb+rules overwrites
> 99-myrule.rules, that shouldn't happen (or at least not randomly).
>
> For more detail, the relevant parts are:
>
> 90-foo.hwdb entry with a dmi match that assigns a property
>
> libinput:name:*Lid Switch*:dmi:*:ct9:*
>  LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=reliable
>
> and the matching 90-foo.rules:
> KERNELS=="input*", \
>   IMPORT{builtin}="hwdb 'libinput:name:$attr{name}:$
> attr{[dmi/id]modalias}'"
>
> This assigns 'reliable' to the device.
>
> I also have per-device udev rules, 92-foo.rules, in this case:
>
> ATTRS{name}=="litest Lid Switch Surface3*", \
> ENV{ID_INPUT_SWITCH}="1", \
> ENV{LIBINPUT_ATTR_LID_SWITCH_RELIABILITY}="write_open"
>
> This overwrites 'reliable' with 'write_open'.
>
> On test-runner start, we install all the udev rules and hwdb files, run
> hwdb
> --update and then start the tests.
>
> In *most* cases, 'write_open' is correctly assigned to the device. In the
> failure cases, 'reliable' is assigned. Nothing changes in the udevadm test
> output and I've verified that the order appears to change, in the failure
> cases the 92-foo.rules applies before the hwdb overwrites it:
>
> ATTRS{name}=="litest Lid Switch Surface3*",
> ENV{ID_INPUT_SWITCH}="1",
> ENV{BONGO}="litest",
> ENV{LIBINPUT_ATTR_LID_SWITCH_RELIABILITY}="write_open"
>
> ATTRS{name}=="litest Lid Switch Surface3*",
> ENV{FIRSTVAL}="$env{LIBINPUT_ATTR_LID_SWITCH_RELIABILITY}"
>
> Running with this udev rule shows that FIRSTVAL is write_open but the real
> property is 'reliable'.
>
> This happens anywhere between 1 out of 3 and 1 out of 50, though it seems
> to
> be more common when creating/removing uinput devices like crazy.


Here's a wild guess...

I wonder if the race condition is in ATTRS{}; attributes are not cached but
read directly from sysfs, and for ATTRS udev has to go upwards the entire
/sys hierarchy – for each and every rule, I believe.

So it could be that some rules do not match because by that time the device
has already disappeared. What happens if you change the rules to rely
entirely on ENV{} matches?

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

Re: [systemd-devel] systemd-sysusers

[Reindl Harald]

Am 05.02.2018 um 10:47 schrieb Michael Chapman:

On Mon, 5 Feb 2018, Reindl Harald wrote:

Am 05.02.2018 um 06:56 schrieb Michael Chapman:

 On Mon, 5 Feb 2018, Johannes Ernst wrote:

 It appears systemd-sysusers does not create home directories. On the
 other hand, it picks (largely unpredictable) UIDs from a range.

 So I have to run systemd-sysusers, and after that, find the UID of the
 user and chown the home directory? Or is there the equivalent of the
 “useradd -m” flag somewhere that I’m just not seeing?


 systemd-sysusers is, as the name suggests, really for _system_ 
users, and

 often those kinds of users don't have ordinary home directories -- that
 is, ones the user can actually write to.

 However, systemd-sysusers.service is ordered before
 systemd-tmpfiles-setup.service at boot, so if you need to create a 
system
 user's home directory and ensure its ownership is correct, you could 
use a

 corresponding tmpfiles.d fragment to do so.


i hope you meant systemd-tmpfiles-setup.service is ordered before 
systemd-sysusers.service and you simply talked about "Before=" which 
in fact means ordered after


Sorry, I cannot work out what you are saying.

Take a look at the unit files as shipped in systemd. 
systemd-tmpfiles-setup.service is ordered After=systemd-sysusers.service 
(which is, as far as I can tell, equivalent to what I said before). It 
needs to be that way around for a tmpfiles.d fragment to be able to 
reference a user created by systemd-sysusers.


buffer overflow - coffee missing - sorry
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers

[Michael Chapman]

On Mon, 5 Feb 2018, Reindl Harald wrote:

Am 05.02.2018 um 06:56 schrieb Michael Chapman:

 On Mon, 5 Feb 2018, Johannes Ernst wrote:

 It appears systemd-sysusers does not create home directories. On the
 other hand, it picks (largely unpredictable) UIDs from a range.

 So I have to run systemd-sysusers, and after that, find the UID of the
 user and chown the home directory? Or is there the equivalent of the
 “useradd -m” flag somewhere that I’m just not seeing?


 systemd-sysusers is, as the name suggests, really for _system_ users, and
 often those kinds of users don't have ordinary home directories -- that
 is, ones the user can actually write to.

 However, systemd-sysusers.service is ordered before
 systemd-tmpfiles-setup.service at boot, so if you need to create a system
 user's home directory and ensure its ownership is correct, you could use a
 corresponding tmpfiles.d fragment to do so.


i hope you meant systemd-tmpfiles-setup.service is ordered before 
systemd-sysusers.service and you simply talked about "Before=" which in fact 
means ordered after


Sorry, I cannot work out what you are saying.

Take a look at the unit files as shipped in systemd. 
systemd-tmpfiles-setup.service is ordered After=systemd-sysusers.service 
(which is, as far as I can tell, equivalent to what I said before). It 
needs to be that way around for a tmpfiles.d fragment to be able to 
reference a user created by systemd-sysusers.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers

[Mantas Mikulėnas]

On Mon, Feb 5, 2018 at 11:26 AM, Reindl Harald 
wrote:

>
>
> Am 05.02.2018 um 06:56 schrieb Michael Chapman:
>
>> On Mon, 5 Feb 2018, Johannes Ernst wrote:
>>
>>> It appears systemd-sysusers does not create home directories. On the
>>> other hand, it picks (largely unpredictable) UIDs from a range.
>>>
>>> So I have to run systemd-sysusers, and after that, find the UID of the
>>> user and chown the home directory? Or is there the equivalent of the
>>> “useradd -m” flag somewhere that I’m just not seeing?
>>>
>>
>> systemd-sysusers is, as the name suggests, really for _system_ users, and
>> often those kinds of users don't have ordinary home directories -- that is,
>> ones the user can actually write to.
>>
>> However, systemd-sysusers.service is ordered before
>> systemd-tmpfiles-setup.service at boot, so if you need to create a system
>> user's home directory and ensure its ownership is correct, you could use a
>> corresponding tmpfiles.d fragment to do so.
>>
>
> i hope you meant systemd-tmpfiles-setup.service is ordered before
> systemd-sysusers.service and you simply talked about "Before=" which in
> fact means ordered after


"Before=" means before. "After=" means after. If Unit A has "After=B", then
A is ordered after B.

$ systemctl cat systemd-tmpfiles-setup.service
# /usr/lib/systemd/system/systemd-tmpfiles-setup.service
…
[Unit]
Description=Create Volatile Files and Directories
Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8)
DefaultDependencies=no
Conflicts=shutdown.target
*After=local-fs.target systemd-sysusers.service*


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

Re: [systemd-devel] hash context not closed.

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 05, 2018 at 09:17:52AM +0100, Stef Bon wrote:
> Same error here:
> (gcry_md_open without gcry_md_close)
> line 901 in src/resolve/resolved-dns-sec.c
> while in the same file at 1227 it's done the good way.

Indeed. PR submitted: https://github.com/systemd/systemd/pull/8100.

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

Re: [systemd-devel] systemd-sysusers

[Reindl Harald]

Am 05.02.2018 um 06:56 schrieb Michael Chapman:

On Mon, 5 Feb 2018, Johannes Ernst wrote:
It appears systemd-sysusers does not create home directories. On the 
other hand, it picks (largely unpredictable) UIDs from a range.


So I have to run systemd-sysusers, and after that, find the UID of the 
user and chown the home directory? Or is there the equivalent of the 
“useradd -m” flag somewhere that I’m just not seeing?


systemd-sysusers is, as the name suggests, really for _system_ users, 
and often those kinds of users don't have ordinary home directories -- 
that is, ones the user can actually write to.


However, systemd-sysusers.service is ordered before 
systemd-tmpfiles-setup.service at boot, so if you need to create a 
system user's home directory and ensure its ownership is correct, you 
could use a corresponding tmpfiles.d fragment to do so.


i hope you meant systemd-tmpfiles-setup.service is ordered before 
systemd-sysusers.service and you simply talked about "Before=" which in 
fact means ordered after


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

Re: [systemd-devel] hash context not closed.

[Stef Bon]

Same error here:
(gcry_md_open without gcry_md_close)
line 901 in src/resolve/resolved-dns-sec.c
while in the same file at 1227 it's done the good way.

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