Re: [systemd-devel] Who deals with the signals of "InterfacesAdded" ?
hi Lennart, Oh! I understand. Thanks you very much. thanks, Byron At 2020-04-10 01:02:17, "Lennart Poettering" wrote: >On Do, 09.04.20 21:27, www (ouyangxua...@163.com) wrote: > >> Dear all, >> >> when I add a new object to dbus, and will send a signal(named >> InterfacesAdded) to "org.freedesktop.Dbus.ObjectManager". I want to >> ask, who is going to handle this signal? What did it do? Where is >> the code? > >Note sure I understand the question. > >On D-Bus signals are broadcast to the bus and anyone who is interested >can subscribe to them. That can be one peer, or many peers or zero >peers. If you are writing a service yourself, and don#t write a >matching client, then of course most likely nobody is going to >subscribe to your signal and it will just be dropped by the broker. > >Lennart > >-- >Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd_bus_add_match callback
Hello Systemd developers!
> I asked this question earlier but I haven’t gotten any reply so I thought
> asking again.
> Question regarding sd_bus_add_match (sd-bus.c):
>
> Is there any bad consequences to use the same callback for multiple signal
> match and then using the userdata parameter to distinguish among the
> different signals? See the sample code below for a reference of what I am
> trying to do.
>
> /*Beginning=*/
> int callback(sd_bus_message *message, void *userdata, sd_bus_error *error) {
> //there should be a lock applied here?
> if(get_signal_id(userdata) == 1) {
> //do something
> }
> }
>
> int main(...) {
> r = sd_bus_add_match(bus, &slot, "type='signal'", test_callback, userdata);
> int r;
> sd_bus *bus = NULL;
> sd_event *event = NULL;
> sd_bus_slot *slot = NULL;
>
> r = sd_bus_default_system(&bus);
> assert(r >= 0);
>
> r = sd_event_default(&event);
> assert(r >= 0);
>
> void *userdata1 = set_signal_id(1);
> r = sd_bus_add_match(bus, &slot,
> "type='signal',interface='org.interface2'", callback, userdata1);
>
> void *userdata2 = set_signal_id(2);
> r = sd_bus_add_match(bus, &slot,
> "type='signal',interface='org.interface1'", callback, userdata2);
>
> r = sd_event_loop(event);
> assert(r >= 0);
>
> bus = sd_bus_flush_close_unref(bus);
> slot = sd_bus_slot_unref(slot);
> event = sd_event_unref(event);
> }
>
> /*End =*/
>
> I appreciate your help and your time.
>
> Thank you,
> David J (ema...@icloud.com)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Who deals with the signals of "InterfacesAdded" ?
On Do, 09.04.20 21:27, www (ouyangxua...@163.com) wrote: > Dear all, > > when I add a new object to dbus, and will send a signal(named > InterfacesAdded) to "org.freedesktop.Dbus.ObjectManager". I want to > ask, who is going to handle this signal? What did it do? Where is > the code? Note sure I understand the question. On D-Bus signals are broadcast to the bus and anyone who is interested can subscribe to them. That can be one peer, or many peers or zero peers. If you are writing a service yourself, and don#t write a matching client, then of course most likely nobody is going to subscribe to your signal and it will just be dropped by the broker. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] reboot on emergency.target
вт, 7 апр. 2020 г. в 14:09, Lennart Poettering : > > On Di, 07.04.20 11:26, Matwey V. Kornilov (matwey.korni...@gmail.com) wrote: > > > Hi, > > > > I would like my system to reboot (with some cool down timeout) on > > emergency.target instead of running the emergency shell. What would be > > the recommended way to achieve this behavior? Is it ok just to override > > default emergency.service to whatever I want? > > Just override emergency.service in /etc/systemd/system/ with a service > of your own, that sleeps and then issues "systemctl reboot". > > You could also just mask the service and pull in a different service > instead. Or you could mask it + pull in reboot.target as a dependency > from emergency.target via a .wants/ symlink (but then you woudln't get > your cool down timout). Thank you for the explanation. However, when I mask emergency.service and add-wants reboot.target, then emergency.target cannot be isolated anymore: # systemctl isolate emergency.target Failed to start emergency.target: Unit emergency.service is masked. > > Lennart > > -- > Lennart Poettering, Berlin -- With best regards, Matwey V. Kornilov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Who deals with the signals of "InterfacesAdded" ?
Dear all, when I add a new object to dbus, and will send a signal(named InterfacesAdded) to "org.freedesktop.Dbus.ObjectManager". I want to ask, who is going to handle this signal? What did it do? Where is the code? thanks, Byron___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] All non-seat0 input devices leak into VT if no display server on seat0
On Thu, Apr 09, 2020 at 02:28:13PM +0300, Pekka Paalanen wrote: > On Thu, 9 Apr 2020 13:01:56 +0200 > Michał Zegan wrote: > > > W dniu 09.04.2020 o 10:23, Pekka Paalanen pisze: > > > On Thu, 9 Apr 2020 09:46:08 +0200 > > > Lennart Poettering wrote: > > > > > >> On Fr, 03.04.20 10:28, Pekka Paalanen (ppaala...@gmail.com) wrote: > > >> > > My (maybe bad) guess is that it would need to be addressed in the > > kernel though > > And the CanMultiSession attribute on non-seat0 doesn't matter when the > > problem > > is all input from all devices gets sent to seat0 when seat0 is in a > > text mode > > TTY > > > > ..and even if you have some kmscon like thing installed, there could > > still be > > text mode TTYs > > >>> > > >>> Hi, > > >>> > > >>> that is both an excellent and horrifying observation. And it makes > > >>> perfect sense to me why that happens, just like you think: seat > > >>> assignments happen in userspace as udev properties. Someone would have > > >>> to explicitly tell the kernel about it too to fix this, e.g. remove > > >>> non-seat0 devices from the VT machinery. > > >>> > > >>> I wonder if such kernel interface even exists? > > >> > > >> There are ioctls for that in the input layer if iirc, but i don't > > >> remember how precisely this works. You are hacking on a compositor, you > > >> should know ;-) > > > > > > Hi, > > > > > > while hacking on a compositor, I have never needed to stop specific > > > input devices from being routed to the VT system while allowing others. > > > If a compositor runs on seat0, it will disable the whole VT input side > > > (among other things) with one VT ioctl IIRC. In this case that is not > > > wanted, because seat0 is intended to be used with the VT text mode and > > > VT input, so disabling all VT input would stop also the wanted input. > > Not sure if it's related and I don't know details, but some software > > like brltty or a fenrir console screenreader are routinely taking > > control over single input devices in text mode. The whole point is that > > they take control over all real keyboards, and have some uinput device > > that is still wired to vt, so that I can send keypresses not supported > > by terminals like insert+something, and these that do not map to > > screenreader would be injected to the uinput and appear on vt. > > I thought display servers also take exclusive control over specific > > input devices... hmm. If they do then this behavior should likely not be > > happening as they still are in control of the devices. > > Hi, > > I have heard of the evdev grab ioctl, which does pretty much what you > describe. I seem to recall there to be a reason why display servers > should not use it, but I have forgot. Maybe it is exactly because of > the kind of use cases you describe though: some special software that > wants to intercept some very specific input devices. If the display > server itself used that same mechanism, then the special software > cannot do its job. > > Peter, would you know? EVIOCGRAB is the ioctl, takes a boolean and when a grab is active it allows for only one consumer of the evdev events. However: this 'one consumer' policy includes in-kernel consumers of those events. We used to grab the device unconditionally the evdev xorg driver 10-ish years ago and it stops things like rfkill from working correctly [1]. so eventually we fixed all the server bits that we didn't need the grab anymore. the synaptics driver did it for a long time too because it was harmless and was the cheap way to avoid duplicate events if the same device was added twice which was a bit of a problem back then. There's a legitimate reason for the grabs and that is basically the use-case of redirecting a device. You *could* work around that now with LIBINPUT_IGNORE_DEVICE on the original device but that's not as flexible as a run-time grab. These cases also prevent the display server from grabbing a device, if say libinput had an EVIOCGRAB on all devices you couldn't run brltty anymore. or at least not *after* libinput started up. Cheers, Peter [1] and things like /dev/input/mice but don't quote me on that, I'd have to test this but it doesn't matter much anymore anyway. > > > > > > Also a display server that runs on non-seat0 seat should never touch > > > anything about VTs AFAIU. I would expect it to not have the permissions > > > to do that even if it wanted to. > > > > > > Like you said it being a kernel or logind bug, this is something that > > > needs to be taken care of below the compositor, automatically keyed by > > > the input device seat assignments. > > > > > > > > > Thanks, > > > pq ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] All non-seat0 input devices leak into VT if no display server on seat0
On Thu, 9 Apr 2020 13:01:56 +0200 Michał Zegan wrote: > W dniu 09.04.2020 o 10:23, Pekka Paalanen pisze: > > On Thu, 9 Apr 2020 09:46:08 +0200 > > Lennart Poettering wrote: > > > >> On Fr, 03.04.20 10:28, Pekka Paalanen (ppaala...@gmail.com) wrote: > >> > My (maybe bad) guess is that it would need to be addressed in the kernel > though > And the CanMultiSession attribute on non-seat0 doesn't matter when the > problem > is all input from all devices gets sent to seat0 when seat0 is in a text > mode > TTY > > ..and even if you have some kmscon like thing installed, there could > still be > text mode TTYs > >>> > >>> Hi, > >>> > >>> that is both an excellent and horrifying observation. And it makes > >>> perfect sense to me why that happens, just like you think: seat > >>> assignments happen in userspace as udev properties. Someone would have > >>> to explicitly tell the kernel about it too to fix this, e.g. remove > >>> non-seat0 devices from the VT machinery. > >>> > >>> I wonder if such kernel interface even exists? > >> > >> There are ioctls for that in the input layer if iirc, but i don't > >> remember how precisely this works. You are hacking on a compositor, you > >> should know ;-) > > > > Hi, > > > > while hacking on a compositor, I have never needed to stop specific > > input devices from being routed to the VT system while allowing others. > > If a compositor runs on seat0, it will disable the whole VT input side > > (among other things) with one VT ioctl IIRC. In this case that is not > > wanted, because seat0 is intended to be used with the VT text mode and > > VT input, so disabling all VT input would stop also the wanted input. > Not sure if it's related and I don't know details, but some software > like brltty or a fenrir console screenreader are routinely taking > control over single input devices in text mode. The whole point is that > they take control over all real keyboards, and have some uinput device > that is still wired to vt, so that I can send keypresses not supported > by terminals like insert+something, and these that do not map to > screenreader would be injected to the uinput and appear on vt. > I thought display servers also take exclusive control over specific > input devices... hmm. If they do then this behavior should likely not be > happening as they still are in control of the devices. Hi, I have heard of the evdev grab ioctl, which does pretty much what you describe. I seem to recall there to be a reason why display servers should not use it, but I have forgot. Maybe it is exactly because of the kind of use cases you describe though: some special software that wants to intercept some very specific input devices. If the display server itself used that same mechanism, then the special software cannot do its job. Peter, would you know? Thanks, pq > > > > Also a display server that runs on non-seat0 seat should never touch > > anything about VTs AFAIU. I would expect it to not have the permissions > > to do that even if it wanted to. > > > > Like you said it being a kernel or logind bug, this is something that > > needs to be taken care of below the compositor, automatically keyed by > > the input device seat assignments. > > > > > > Thanks, > > pq pgpSiq4hogvC5.pgp Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] The meaning of CanMultiSession=no on non-seat0
W dniu 09.04.2020 o 10:23, Pekka Paalanen pisze: > On Thu, 9 Apr 2020 09:46:08 +0200 > Lennart Poettering wrote: > >> On Fr, 03.04.20 10:28, Pekka Paalanen (ppaala...@gmail.com) wrote: >> My (maybe bad) guess is that it would need to be addressed in the kernel though And the CanMultiSession attribute on non-seat0 doesn't matter when the problem is all input from all devices gets sent to seat0 when seat0 is in a text mode TTY ..and even if you have some kmscon like thing installed, there could still be text mode TTYs >>> >>> Hi, >>> >>> that is both an excellent and horrifying observation. And it makes >>> perfect sense to me why that happens, just like you think: seat >>> assignments happen in userspace as udev properties. Someone would have >>> to explicitly tell the kernel about it too to fix this, e.g. remove >>> non-seat0 devices from the VT machinery. >>> >>> I wonder if such kernel interface even exists? >> >> There are ioctls for that in the input layer if iirc, but i don't >> remember how precisely this works. You are hacking on a compositor, you >> should know ;-) > > Hi, > > while hacking on a compositor, I have never needed to stop specific > input devices from being routed to the VT system while allowing others. > If a compositor runs on seat0, it will disable the whole VT input side > (among other things) with one VT ioctl IIRC. In this case that is not > wanted, because seat0 is intended to be used with the VT text mode and > VT input, so disabling all VT input would stop also the wanted input. Not sure if it's related and I don't know details, but some software like brltty or a fenrir console screenreader are routinely taking control over single input devices in text mode. The whole point is that they take control over all real keyboards, and have some uinput device that is still wired to vt, so that I can send keypresses not supported by terminals like insert+something, and these that do not map to screenreader would be injected to the uinput and appear on vt. I thought display servers also take exclusive control over specific input devices... hmm. If they do then this behavior should likely not be happening as they still are in control of the devices. > > Also a display server that runs on non-seat0 seat should never touch > anything about VTs AFAIU. I would expect it to not have the permissions > to do that even if it wanted to. > > Like you said it being a kernel or logind bug, this is something that > needs to be taken care of below the compositor, automatically keyed by > the input device seat assignments. > > > Thanks, > pq > > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] The meaning of CanMultiSession=no on non-seat0
On Thu, 9 Apr 2020 09:46:08 +0200 Lennart Poettering wrote: > On Fr, 03.04.20 10:28, Pekka Paalanen (ppaala...@gmail.com) wrote: > > > > My (maybe bad) guess is that it would need to be addressed in the kernel > > > though > > > And the CanMultiSession attribute on non-seat0 doesn't matter when the > > > problem > > > is all input from all devices gets sent to seat0 when seat0 is in a text > > > mode > > > TTY > > > > > > ..and even if you have some kmscon like thing installed, there could > > > still be > > > text mode TTYs > > > > Hi, > > > > that is both an excellent and horrifying observation. And it makes > > perfect sense to me why that happens, just like you think: seat > > assignments happen in userspace as udev properties. Someone would have > > to explicitly tell the kernel about it too to fix this, e.g. remove > > non-seat0 devices from the VT machinery. > > > > I wonder if such kernel interface even exists? > > There are ioctls for that in the input layer if iirc, but i don't > remember how precisely this works. You are hacking on a compositor, you > should know ;-) Hi, while hacking on a compositor, I have never needed to stop specific input devices from being routed to the VT system while allowing others. If a compositor runs on seat0, it will disable the whole VT input side (among other things) with one VT ioctl IIRC. In this case that is not wanted, because seat0 is intended to be used with the VT text mode and VT input, so disabling all VT input would stop also the wanted input. Also a display server that runs on non-seat0 seat should never touch anything about VTs AFAIU. I would expect it to not have the permissions to do that even if it wanted to. Like you said it being a kernel or logind bug, this is something that needs to be taken care of below the compositor, automatically keyed by the input device seat assignments. Thanks, pq pgpuxzIOa4N0o.pgp Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] The meaning of CanMultiSession=no on non-seat0
On Fr, 03.04.20 10:28, Pekka Paalanen (ppaala...@gmail.com) wrote: > > My (maybe bad) guess is that it would need to be addressed in the kernel > > though > > And the CanMultiSession attribute on non-seat0 doesn't matter when the > > problem > > is all input from all devices gets sent to seat0 when seat0 is in a text > > mode > > TTY > > > > ..and even if you have some kmscon like thing installed, there could still > > be > > text mode TTYs > > Hi, > > that is both an excellent and horrifying observation. And it makes > perfect sense to me why that happens, just like you think: seat > assignments happen in userspace as udev properties. Someone would have > to explicitly tell the kernel about it too to fix this, e.g. remove > non-seat0 devices from the VT machinery. > > I wonder if such kernel interface even exists? There are ioctls for that in the input layer if iirc, but i don't remember how precisely this works. You are hacking on a compositor, you should know ;-) Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] The meaning of CanMultiSession=no on non-seat0
On Do, 02.04.20 22:59, nerdopolis (bluescreen_aven...@verizon.net) wrote: > Thanks. I was wondering if there was some security thing that depended on TTYs > for the two Display Servers running on the same seat to truly be secure or > not. > (like reading /dev/input/* ) The input subsystem has ioctls we use to switch access. THis should be reasonably secure. DRM the same. > If you don't need TTYs to prevent the non-seat0 session from reading input > from > the other non-seat0 session, the same as on seat0, then yeah, as I've been > able > to run and switch between two sessions on non-seat0 since I first tried it in > 2017... keypresses these days are read via the input subsystems, ttys are only used for classic text logins at this point. > One thing I did notice though is that (as far as leaking input) > > - if run Display Servers on the secondary seat (one, or more than one) > - On seat0, I chvt to a text-mode TTY > - Continuing to use the secondary seat, all keyboard and mouse (gpm) input > gets sent to the TTY (and the actual display server) > - Switching back to a TTY with a display server, and the seats behave separate > again hmm, this smells like a bug, either in logind or in the kernel. can you file an issue about this? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd && fanotify / path activation
On Mi, 08.04.20 20:58, Andy Pieters (syst...@andypieters.me.uk) wrote: > Hi list > > I'm trying to satisfy PCI requirements by having on-access virus > scanning on servers involved with card-holder data. > > Normally we could use clamav which has got on-access scanning, but > this has been removed > > Could we get systemd to help out by using its fanotify start a unit to > scan an object > > I'm just thinking out loud here but is it possible to have a wildcard > path unit? then drill down on the exact reason > > No I'm probably thinking about it the wrong way > > Any thoughts from the list please? So there has been a TODO list item about adding fanotify support to .path units, since fanotify can do some interesting things that inotify can't. Howevre, this is mostly the async stuff in fanotify. For the anti-virus stuff you'd need the sync stuff in fanotify, i.e. where fs access hangs until the fanotify-used program acknowledges it. I doubt this would fit into the .path unit concept, which is very asynchronous, very "coalescing" in behaviour. i.e. a mechanism where every individual request needs to be ack'ed doesn't fit into it. Behaviour like that probably would probably fit better into the .socket concept, which actually is about more than just pure sockets, it already can listen on FIFOs, msgqs, USB functions and and "special files". Maybe a ListenFileAccessNotify= could be added that does what you need. This would then mean that PID 1 would establish the fanotify watch, and wait for POLLIN on it, and as soon as that happens fork off some service and pass the fanotify fd to it. The service would have to read the event off it and acknowledge it. It could then exit after a while. Would that work for you? If so, prep a PR and submit it, would be happy to review it. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
