[systemd-devel] [PATCH] manager: Ensure user's systemd runtime directory exists.
This mirrors code in dbus.c when creating the private socket and
avoids error messages like:
systemd[1353]: bind(/run/user/603/systemd/notify) failed: No such file or
directory
systemd[1353]: Failed to fully start up daemon: No such file or directory
---
src/core/manager.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/core/manager.c b/src/core/manager.c
index ed7fdc7..2c77757 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -662,9 +662,11 @@ static int manager_setup_notify(Manager *m) {
return -errno;
}
-if (m-running_as == SYSTEMD_SYSTEM)
+if (m-running_as == SYSTEMD_SYSTEM) {
m-notify_socket = strdup(/run/systemd/notify);
-else {
+if (!m-notify_socket)
+return log_oom();
+} else {
const char *e;
e = getenv(XDG_RUNTIME_DIR);
@@ -674,9 +676,11 @@ static int manager_setup_notify(Manager *m) {
}
m-notify_socket = strappend(e, /systemd/notify);
+if (!m-notify_socket)
+return log_oom();
+
+mkdir_parents_label(m-notify_socket, 0755);
}
-if (!m-notify_socket)
-return log_oom();
strncpy(sa.un.sun_path, m-notify_socket,
sizeof(sa.un.sun_path)-1);
r = bind(fd, sa.sa, offsetof(struct sockaddr_un, sun_path) +
strlen(sa.un.sun_path));
--
2.1.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] v217: ordering cycle issue
With v217 one of my boxes stopped starting mysqld.service ... as I looked closer I found that its tmpfiles weren't set up correctly In journalctl I found that the setup of tmpfiles was skipped in a way: Nov 02 13:33:55 goto.oops.intern systemd[1]: Found dependency on basic.target/start Nov 02 13:33:55 goto.oops.intern systemd[1]: Breaking ordering cycle by deleting job systemd-tmpfiles-setup.service/start Nov 02 13:33:55 goto.oops.intern systemd[1]: Job systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with basic.target/start Downgrading to v216 solved it for me, now I see that other gentoo-users hit the same issues: https://bugs.gentoo.org/show_bug.cgi?id=527894 How can I pinpoint what's wrong here? Does anyone else see this behavior (with other distros)? Thanks for any help on this, regards, Stefan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] v217: ordering cycle issue
Am 02.11.2014 um 14:57 schrieb Stefan G. Weichinger: Downgrading to v216 solved it for me, now I see that other gentoo-users hit the same issues: https://bugs.gentoo.org/show_bug.cgi?id=527894 How can I pinpoint what's wrong here? Does anyone else see this behavior (with other distros)? Ah, we found something already and tested it OK: http://cgit.freedesktop.org/systemd/systemd/commit/?id=919699ec301ea507edce4a619141ed22e789ac0d ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [HEADSUP] First piece of PPPoE support
Hi, I just committed a library to negotiate PPPoE channels. Note that we still need a PPP library before this is useful in practice. However, comments on the code and testing on real networks would be very much appreciated. See the commit message for details: http://cgit.freedesktop.org/systemd/systemd/commit/?id=cda391c3f9c85578f4a4fe81d4aeb785a785000a. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] unit: do not order timers.target before basic.target
Since commit 19f8d037833f2 'timer: order OnCalendar units after timer-sync.target if DefaultDependencies=no' timers might get a dependency on time-sync.target, which does not really belong in early boot. If ntp is enabled, time-sync.target might be delayed until a network connection is established. It turns out that majority of timer units found in the wild do not need to be started in early boot. Out of the timer units available in Fedora 21, only systemd-readahead-done.timer and mdadm-last-resort@.timer should be started early, but they both have DefaultDependencies=no, so are not part of timers.target anyway. All the rest look like they will be fine with being started a bit later (and the majority even much later, since they run daily or weekly). Let timers.target be pulled in by basic.target, but without the temporal dependency. This means timer units are started on a best effort schedule. https://bugzilla.redhat.com/show_bug.cgi?id=1158206 --- I intend to push this fairly quickly, if there are no objections. units/basic.target | 5 - units/timers.target | 3 +++ 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/units/basic.target b/units/basic.target index 228f62c4b1..eee3e6b774 100644 --- a/units/basic.target +++ b/units/basic.target @@ -8,8 +8,11 @@ [Unit] Description=Basic System Documentation=man:systemd.special(7) + Requires=sysinit.target +After=sysinit.target Wants=sockets.target timers.target paths.target slices.target -After=sysinit.target sockets.target timers.target paths.target slices.target +After=sockets.target paths.target slices.target + JobTimeoutSec=15min JobTimeoutAction=poweroff-force diff --git a/units/timers.target b/units/timers.target index 07fda3d9d0..251fa68065 100644 --- a/units/timers.target +++ b/units/timers.target @@ -8,3 +8,6 @@ [Unit] Description=Timers Documentation=man:systemd.special(7) + +DefaultDependencies=no +Conflicts=shutdown.target -- 2.1.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/5] calendar: semesterly alias for semi-annually
On Sun, Nov 02, 2014 at 02:35:53PM +0100, Daniele Medri wrote:
yes, it's needed because all other terms are youNameIt-ly friendly.
With this one, the patch 2/5 could be useful for semesterly alias and
the man page revision.
Sorry, but I don't understand what you mean. Sorting the code and man page
by unit length is OK, but I don't see how that implies adding another alias
to existing name. Semi-anually is nice and clear.
Zbyszek
[adding cc:systemd-devel which I dropped by mistake previously.]
Take a look at 3/5-patch and 5/5-patch too. Are easy/needed changes.
2014-11-01 20:27 GMT+01:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl:
On Thu, Oct 30, 2014 at 12:19:11PM +0100, Daniele Medri wrote:
---
man/systemd.time.xml | 4 ++--
src/shared/calendarspec.c| 3 ++-
src/test/test-calendarspec.c | 1 +
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/man/systemd.time.xml b/man/systemd.time.xml
index f35ccd7..2342684 100644
--- a/man/systemd.time.xml
+++ b/man/systemd.time.xml
@@ -247,8 +247,8 @@
literalmonthly/literal, literalweekly/literal,
literalyearly/literal,
literalquarterly/literal,
-literalsemiannually/literal may be used as
-calendar events which refer to
+ literalsemesterly/literal or
literalsemiannually/literal
+ may be used as calendar events which refer to
Pluralitas non est ponenda sine necessitate. Is there a good reason, like
compatiblity with existing usage for this adition?
Zbyszek
literal*-*-* *:*:00/literal,
literal*-*-* *:00:00/literal,
literal*-*-* 00:00:00/literal,
diff --git a/src/shared/calendarspec.c b/src/shared/calendarspec.c
index 7efcf7b..3115bba 100644
--- a/src/shared/calendarspec.c
+++ b/src/shared/calendarspec.c
@@ -757,7 +757,8 @@ int calendar_spec_from_string(const char *p,
CalendarSpec **spec) {
} else if (strcaseeq(p, biannually) ||
strcaseeq(p, bi-annually) ||
strcaseeq(p, semiannually) ||
- strcaseeq(p, semi-annually)) {
+ strcaseeq(p, semi-annually) ||
+ strcaseeq(p, semesterly)) {
r = const_chain(1, c-month);
if (r 0)
diff --git a/src/test/test-calendarspec.c b/src/test/test-calendarspec.c
index 87e1da1..7610cff 100644
--- a/src/test/test-calendarspec.c
+++ b/src/test/test-calendarspec.c
@@ -80,6 +80,7 @@ int main(int argc, char* argv[]) {
test_one(minutely, *-*-* *:*:00);
test_one(quarterly, *-01,04,07,10-01 00:00:00);
test_one(semi-annually, *-01,07-01 00:00:00);
+test_one(semesterly, *-01,07-01 00:00:00);
test_one(annually, *-01-01 00:00:00);
test_one(*:2/3, *-*-* *:02/3:00);
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Daniele Medri
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Dbus user/system session
Here are the unit files I use to start my user Dbus session daemon /home/gabx/.config/systemd/user/dbus.service [Unit] Description=D-Bus System Message Bus Requires=dbus.socket [Service] ExecStart=/usr/bin/dbus-daemon --session --address=systemd: --nofork --systemd-activation ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig [Install] WantedBy=default.target /home/gabx/.config/systemd/user/dbus.socket -- [Unit] Description = D-Bus System Message Bus Socket [Socket] ListenStream = %t/dbus/user_bus_socket [Install] WantedBy=dbus.target WantedBy=sockets.target It seems everything is Ok as Dbus is doing its job. gabx@hortensia ➤➤ ~aur % systemctl --user status ● hortensia State: running Jobs: 0 queued Failed: 0 units Since: Sun 2014-11-02 11:58:45 CET; 6h ago CGroup: /user.slice/user-1000.slice/user@1000.service ├─839 /usr/lib/systemd/systemd --user ├─840 (sd-pam) ├─dbus.service │ └─855 /usr/bin/dbus-daemon --session --address=systemd: --nofork --systemd-activation Now when I list dbus process, here is the output: 118:dbus 588 1 0 11:58 ?00:00:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation 126:gabx 855 839 0 11:58 ?00:00:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --systemd-activation 132:dbus 892 461 0 11:58 ?00:00:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation 152:gabx 1485 1 0 11:58 ?00:00:00 /usr/bin/dbus-launch --autolaunch 77f348a2b3fb429b85a5de751ea9175a --binary-syntax --close-stderr 153:gabx 1486 1 0 11:58 ?00:00:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session 155:gabx 1494 1488 0 11:58 ?00:00:00 /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3 As one can see, I have two similar systemd dbus-daemon processes owned by Dbus : PID 588 892. Is it the expected behavior ? Thank you for suggestions. -- google.com/+arnaudgabourygabx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] statelessy system
On Fri, 31.10.14 14:06, Łukasz Stelmach (l.stelm...@samsung.com) wrote: Hello. I am working to upgrade systemd in Tizen to v217 from v212. To verify rpm packages we use rpmlint with some rules from opensuse[1]. For whatever reason v217 package exceed allowed badness because it puts config files (system.conf, journald.conf etc) in /etc/systemd. The check [2] forbids putting anything in there and it seems to go along weel with the sateless system goal of systemd. My question: is v217 ready to run without /etc/systemd/*.conf and read them from /usr/lib/systemd wher I (vendor) can put properly tailored files? Yes, /etc/systemd is unnecessary for booting. If you find any of our tools not working if /etc/systemd is removed it would be a bug. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] manager: Ensure user's systemd runtime directory exists.
On Sun, Nov 02, 2014 at 02:04:20PM +, Colin Guthrie wrote:
This mirrors code in dbus.c when creating the private socket and
avoids error messages like:
systemd[1353]: bind(/run/user/603/systemd/notify) failed: No such file or
directory
systemd[1353]: Failed to fully start up daemon: No such file or directory
Seems reasonable. But why not move the mkdir_parent_label() to the shared
code path? Even if the dir is created elsewhere, it seems cleaner to ensure
here that it is available.
Zbyszek
---
src/core/manager.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/core/manager.c b/src/core/manager.c
index ed7fdc7..2c77757 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -662,9 +662,11 @@ static int manager_setup_notify(Manager *m) {
return -errno;
}
-if (m-running_as == SYSTEMD_SYSTEM)
+if (m-running_as == SYSTEMD_SYSTEM) {
m-notify_socket = strdup(/run/systemd/notify);
-else {
+if (!m-notify_socket)
+return log_oom();
+} else {
const char *e;
e = getenv(XDG_RUNTIME_DIR);
@@ -674,9 +676,11 @@ static int manager_setup_notify(Manager *m) {
}
m-notify_socket = strappend(e, /systemd/notify);
+if (!m-notify_socket)
+return log_oom();
+
+mkdir_parents_label(m-notify_socket, 0755);
}
-if (!m-notify_socket)
-return log_oom();
strncpy(sa.un.sun_path, m-notify_socket,
sizeof(sa.un.sun_path)-1);
r = bind(fd, sa.sa, offsetof(struct sockaddr_un, sun_path)
+ strlen(sa.un.sun_path));
--
2.1.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Supporting U2F over HID on Linux?
I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices that speak a custom protocol. The intent is that user code will speak to then using something like HIDAPI. The trick is that, for HIDAPI to work, something needs to recognize these devices and get udev to set appropriate device permissions. My question is: how should this be done? The official way to enumerate U2F devices is to look for a HID usage page 0xf1d0 containing usage 0x1. Options include: - A builtin udev helper that reads the sysfs report_descriptor for hid or hidraw devices and sets attributes accordingly (either ID_SECURITY_TOKEN or something more general). - A udev helper that does this and doesn't live in the systemd tree. I don't love this option -- I'd prefer for this to be as plug-and-play as possible. - HID core code in the kernel to add HID_USAGES=f1d1:lots:of:other:things to the uevent (or udev code to do the same). This might end up producing a rather long string or some devices. - An actual kernel driver for U2F devices using the hid group mechanism for enumeration. This seems overcomplicated. Concretely, my U2F device is: /devices/pci:00/:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:1050:0120.0011/hidraw/hidraw0 The 0xf1d0 thing is enumerable on /devices/pci:00/:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:1050:0120.0011. Thoughts? --Andy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, 2 Nov 2014, Andy Lutomirski wrote: I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices that speak a custom protocol. The intent is that user code will speak to then using something like HIDAPI. The trick is that, for HIDAPI to work, something needs to recognize these devices and get udev to set appropriate device permissions. Just to make sure we are on the same page -- this is really only about setting proper device node permissions and nothing else, right? My question is: how should this be done? The official way to enumerate U2F devices is to look for a HID usage page 0xf1d0 containing usage 0x1. Options include: - A builtin udev helper that reads the sysfs report_descriptor for hid or hidraw devices and sets attributes accordingly (either ID_SECURITY_TOKEN or something more general). Hmmm ... please keep in mind that report_descriptor is actually in debugfs, so it's a bit questionable whether you can rely on it being present on well-defined location on all systems. You can get it from different other places though, such as libusb (but then you are limited only to USB HID devices ... which might be enough in your particular case). - A udev helper that does this and doesn't live in the systemd tree. I don't love this option -- I'd prefer for this to be as plug-and-play as possible. Agreed. - HID core code in the kernel to add HID_USAGES=f1d1:lots:of:other:things to the uevent (or udev code to do the same). This might end up producing a rather long string or some devices. We have been thinking about this quite a lot in the past, and decided to postpone this until there is a very good reason for it to happen. - An actual kernel driver for U2F devices using the hid group mechanism for enumeration. This seems overcomplicated. Hmmm ... why do you think so? I believe it actually should be really super-trivial. Thanks, -- Jiri Kosina SUSE Labs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
Hi Andy, On Sun, Nov 2, 2014 at 7:57 PM, Andy Lutomirski l...@amacapital.net wrote: I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices that speak a custom protocol. The intent is that user code will speak to then using something like HIDAPI. The trick is that, for HIDAPI to work, something needs to recognize these devices and get udev to set appropriate device permissions. My question is: how should this be done? The official way to enumerate U2F devices is to look for a HID usage page 0xf1d0 containing usage 0x1. Options include: - A builtin udev helper that reads the sysfs report_descriptor for hid or hidraw devices and sets attributes accordingly (either ID_SECURITY_TOKEN or something more general). I don't think we should have such special-purpose logic in the udev core. [...] - HID core code in the kernel to add HID_USAGES=f1d1:lots:of:other:things to the uevent (or udev code to do the same). This might end up producing a rather long string or some devices. This makes the most sense to me. We could put this logic (adapting the patch you posted) in src/udev/udev-builtin-usb_id.c. I'll comment on the patch separately. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, Nov 2, 2014 at 12:42 PM, Jiri Kosina jkos...@suse.cz wrote: On Sun, 2 Nov 2014, Andy Lutomirski wrote: I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices that speak a custom protocol. The intent is that user code will speak to then using something like HIDAPI. The trick is that, for HIDAPI to work, something needs to recognize these devices and get udev to set appropriate device permissions. Just to make sure we are on the same page -- this is really only about setting proper device node permissions and nothing else, right? Yes. My question is: how should this be done? The official way to enumerate U2F devices is to look for a HID usage page 0xf1d0 containing usage 0x1. Options include: - A builtin udev helper that reads the sysfs report_descriptor for hid or hidraw devices and sets attributes accordingly (either ID_SECURITY_TOKEN or something more general). Hmmm ... please keep in mind that report_descriptor is actually in debugfs, so it's a bit questionable whether you can rely on it being present on well-defined location on all systems. Huh? I have /sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:1050:0120.0013/report_descriptor on my system. You can get it from different other places though, such as libusb (but then you are limited only to USB HID devices ... which might be enough in your particular case). I have no idea whether there will ever be a bluetooth U2F device. - A udev helper that does this and doesn't live in the systemd tree. I don't love this option -- I'd prefer for this to be as plug-and-play as possible. Agreed. - HID core code in the kernel to add HID_USAGES=f1d1:lots:of:other:things to the uevent (or udev code to do the same). This might end up producing a rather long string or some devices. We have been thinking about this quite a lot in the past, and decided to postpone this until there is a very good reason for it to happen. I'm not sure that U2F counts as a very good reason. - An actual kernel driver for U2F devices using the hid group mechanism for enumeration. This seems overcomplicated. Hmmm ... why do you think so? I believe it actually should be really super-trivial. The HID group part is trivial, but what interface would the driver expose? I don't think that a udev rule for hidraw matching the modalias makes any sense, and, if it were a real driver, what interface would it expose? Most cross-platform userspace code for U2F is likely to use HIDAPI. Admittedly, a U2F driver in the kernel would be slightly nicer from a multiplexing standpoint than hidraw. --Andy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, Nov 2, 2014 at 12:47 PM, Tom Gundersen t...@jklm.no wrote: Hi Andy, On Sun, Nov 2, 2014 at 7:57 PM, Andy Lutomirski l...@amacapital.net wrote: I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices that speak a custom protocol. The intent is that user code will speak to then using something like HIDAPI. The trick is that, for HIDAPI to work, something needs to recognize these devices and get udev to set appropriate device permissions. My question is: how should this be done? The official way to enumerate U2F devices is to look for a HID usage page 0xf1d0 containing usage 0x1. Options include: - A builtin udev helper that reads the sysfs report_descriptor for hid or hidraw devices and sets attributes accordingly (either ID_SECURITY_TOKEN or something more general). I don't think we should have such special-purpose logic in the udev core. [...] - HID core code in the kernel to add HID_USAGES=f1d1:lots:of:other:things to the uevent (or udev code to do the same). This might end up producing a rather long string or some devices. This makes the most sense to me. We could put this logic (adapting the patch you posted) in src/udev/udev-builtin-usb_id.c. How would that work? Can't a USB device have more than one HID class device under it? I could imagine a future U2F keyboard that has a HID class device for the keyboard part and another one for U2F. --Andy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, 2 Nov 2014, Andy Lutomirski wrote: Hmmm ... please keep in mind that report_descriptor is actually in debugfs, so it's a bit questionable whether you can rely on it being present on well-defined location on all systems. Huh? I have /sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:1050:0120.0013/report_descriptor on my system. Brainfart on my side. We have 'rdesc' and 'events' in debugfs sice a long time, but then 'report_descriptor' has been added as a proper sysfs attribute some time around 3.0. - HID core code in the kernel to add HID_USAGES=f1d1:lots:of:other:things to the uevent (or udev code to do the same). This might end up producing a rather long string or some devices. We have been thinking about this quite a lot in the past, and decided to postpone this until there is a very good reason for it to happen. I'm not sure that U2F counts as a very good reason. It might well be the justifying reason. I'd first like to see what other options we have though. - An actual kernel driver for U2F devices using the hid group mechanism for enumeration. This seems overcomplicated. Hmmm ... why do you think so? I believe it actually should be really super-trivial. The HID group part is trivial, but what interface would the driver expose? I don't think that a udev rule for hidraw matching the modalias makes any sense, and, if it were a real driver, what interface would it expose? Most cross-platform userspace code for U2F is likely to use HIDAPI. Admittedly, a U2F driver in the kernel would be slightly nicer from a multiplexing standpoint than hidraw. Alternatively, you can just write udev rule which triggers on HID devices, issues HIDIOCGRDESC ioctl() on the just-created hidraw node, and decides afterwards whether node permissions need to be altered ... right? Thanks, -- Jiri Kosina SUSE Labs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, 2 Nov 2014, Jiri Kosina wrote: Alternatively, you can just write udev rule which triggers on HID devices, issues HIDIOCGRDESC ioctl() on the just-created hidraw node, and decides afterwards whether node permissions need to be altered ... right? Just to make myself clear here -- this is basically alternative to your 1st option, but for cases where you want to make yourself independent on sysfs existence (I don't what is the craziness level of setups you are considering). -- Jiri Kosina SUSE Labs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, Nov 2, 2014 at 10:13 PM, Andy Lutomirski l...@amacapital.net wrote: On Sun, Nov 2, 2014 at 12:47 PM, Tom Gundersen t...@jklm.no wrote: Hi Andy, On Sun, Nov 2, 2014 at 7:57 PM, Andy Lutomirski l...@amacapital.net wrote: I want to get U2F (universal second factor, sometimes called security key or even gnubby) working on Linux. U2F tokens are HID devices that speak a custom protocol. The intent is that user code will speak to then using something like HIDAPI. The trick is that, for HIDAPI to work, something needs to recognize these devices and get udev to set appropriate device permissions. My question is: how should this be done? The official way to enumerate U2F devices is to look for a HID usage page 0xf1d0 containing usage 0x1. Options include: - A builtin udev helper that reads the sysfs report_descriptor for hid or hidraw devices and sets attributes accordingly (either ID_SECURITY_TOKEN or something more general). I don't think we should have such special-purpose logic in the udev core. [...] - HID core code in the kernel to add HID_USAGES=f1d1:lots:of:other:things to the uevent (or udev code to do the same). This might end up producing a rather long string or some devices. This makes the most sense to me. We could put this logic (adapting the patch you posted) in src/udev/udev-builtin-usb_id.c. How would that work? Can't a USB device have more than one HID class device under it? I could imagine a future U2F keyboard that has a HID class device for the keyboard part and another one for U2F. Right, a separate built-in makes more sense then. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, Nov 2, 2014 at 2:45 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 4:40 PM, Jiri Kosina jkos...@suse.cz wrote: On Sun, 2 Nov 2014, Jiri Kosina wrote: Alternatively, you can just write udev rule which triggers on HID devices, issues HIDIOCGRDESC ioctl() on the just-created hidraw node, and decides afterwards whether node permissions need to be altered ... right? Just to make myself clear here -- this is basically alternative to your 1st option, but for cases where you want to make yourself independent on sysfs existence (I don't what is the craziness level of setups you are considering). I am a little bit concerned with the user space retrieving the descriptor, parsing it and then deciding how to set the permissions. It's not that it is super complex, but it will duplicate the parsing we already do in the kernel. Wacom tried to do that in their usb driver, and they never managed to fully implement one. I think the HID_GROUP solution is super trivial: - add a match on the U2F input report and set the group to HID_GROUP_U2F (2 lines in hid_scan_input_usage() in hid-core.c) - allow hid-generic to also match HID_GROUP_U2F (1 line in hid-generic.c). Then, the udev rule would be super trivial. I'm confused. What would the user-visible effect of this be? Would the hidraw node still show up? What is user code supposed to match to detect a U2F device or to otherwise set permissions? --Andy Also, if we want to further extend the kernel API for U2F, the group will already be in place. Cheers, Benjamin -- Andy Lutomirski AMA Capital Management, LLC ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, Nov 2, 2014 at 5:49 PM, Andy Lutomirski l...@amacapital.net wrote: On Sun, Nov 2, 2014 at 2:45 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 4:40 PM, Jiri Kosina jkos...@suse.cz wrote: On Sun, 2 Nov 2014, Jiri Kosina wrote: Alternatively, you can just write udev rule which triggers on HID devices, issues HIDIOCGRDESC ioctl() on the just-created hidraw node, and decides afterwards whether node permissions need to be altered ... right? Just to make myself clear here -- this is basically alternative to your 1st option, but for cases where you want to make yourself independent on sysfs existence (I don't what is the craziness level of setups you are considering). I am a little bit concerned with the user space retrieving the descriptor, parsing it and then deciding how to set the permissions. It's not that it is super complex, but it will duplicate the parsing we already do in the kernel. Wacom tried to do that in their usb driver, and they never managed to fully implement one. I think the HID_GROUP solution is super trivial: - add a match on the U2F input report and set the group to HID_GROUP_U2F (2 lines in hid_scan_input_usage() in hid-core.c) - allow hid-generic to also match HID_GROUP_U2F (1 line in hid-generic.c). Then, the udev rule would be super trivial. I'm confused. What would the user-visible effect of this be? Would the hidraw node still show up? What is user code supposed to match to detect a U2F device or to otherwise set permissions? The only change with what we currently have is that the modalias of the device will be something like MODALIAS=hid:b0003gHID_GROUP_U2Fvp. (replace HID_GROUP_U2F with the proper hex value). So matching against this modalias is trivial, and you can just put the hidraw node rw for users. The device will still be handled by hid-generic, so there will be no changes besides the modalias. So yes, you still need a udev rule to set the proper permission, but you will not have to parse the report descriptors. Cheers, Benjamin PS: some time spent and I realized that the modalias would be the one of the HID node, which the hidraw is a son. Not the hidraw node directly :/ --Andy Also, if we want to further extend the kernel API for U2F, the group will already be in place. Cheers, Benjamin -- Andy Lutomirski AMA Capital Management, LLC ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, Nov 2, 2014 at 3:01 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 5:49 PM, Andy Lutomirski l...@amacapital.net wrote: On Sun, Nov 2, 2014 at 2:45 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 4:40 PM, Jiri Kosina jkos...@suse.cz wrote: On Sun, 2 Nov 2014, Jiri Kosina wrote: Alternatively, you can just write udev rule which triggers on HID devices, issues HIDIOCGRDESC ioctl() on the just-created hidraw node, and decides afterwards whether node permissions need to be altered ... right? Just to make myself clear here -- this is basically alternative to your 1st option, but for cases where you want to make yourself independent on sysfs existence (I don't what is the craziness level of setups you are considering). I am a little bit concerned with the user space retrieving the descriptor, parsing it and then deciding how to set the permissions. It's not that it is super complex, but it will duplicate the parsing we already do in the kernel. Wacom tried to do that in their usb driver, and they never managed to fully implement one. I think the HID_GROUP solution is super trivial: - add a match on the U2F input report and set the group to HID_GROUP_U2F (2 lines in hid_scan_input_usage() in hid-core.c) - allow hid-generic to also match HID_GROUP_U2F (1 line in hid-generic.c). Then, the udev rule would be super trivial. I'm confused. What would the user-visible effect of this be? Would the hidraw node still show up? What is user code supposed to match to detect a U2F device or to otherwise set permissions? The only change with what we currently have is that the modalias of the device will be something like MODALIAS=hid:b0003gHID_GROUP_U2Fvp. (replace HID_GROUP_U2F with the proper hex value). So matching against this modalias is trivial, and you can just put the hidraw node rw for users. Do we really want udev matching against MODALIAS, and do we really want udev rules to hardcode hid group constants? I'd like this idea better if we added a HID_GROUP uevent property with a textual description, or perhaps something a little more specific. The hid group field seems to be used for different types of things. --Andy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, Nov 2, 2014 at 6:34 PM, Andy Lutomirski l...@amacapital.net wrote: On Sun, Nov 2, 2014 at 3:01 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 5:49 PM, Andy Lutomirski l...@amacapital.net wrote: On Sun, Nov 2, 2014 at 2:45 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 4:40 PM, Jiri Kosina jkos...@suse.cz wrote: On Sun, 2 Nov 2014, Jiri Kosina wrote: Alternatively, you can just write udev rule which triggers on HID devices, issues HIDIOCGRDESC ioctl() on the just-created hidraw node, and decides afterwards whether node permissions need to be altered ... right? Just to make myself clear here -- this is basically alternative to your 1st option, but for cases where you want to make yourself independent on sysfs existence (I don't what is the craziness level of setups you are considering). I am a little bit concerned with the user space retrieving the descriptor, parsing it and then deciding how to set the permissions. It's not that it is super complex, but it will duplicate the parsing we already do in the kernel. Wacom tried to do that in their usb driver, and they never managed to fully implement one. I think the HID_GROUP solution is super trivial: - add a match on the U2F input report and set the group to HID_GROUP_U2F (2 lines in hid_scan_input_usage() in hid-core.c) - allow hid-generic to also match HID_GROUP_U2F (1 line in hid-generic.c). Then, the udev rule would be super trivial. I'm confused. What would the user-visible effect of this be? Would the hidraw node still show up? What is user code supposed to match to detect a U2F device or to otherwise set permissions? The only change with what we currently have is that the modalias of the device will be something like MODALIAS=hid:b0003gHID_GROUP_U2Fvp. (replace HID_GROUP_U2F with the proper hex value). So matching against this modalias is trivial, and you can just put the hidraw node rw for users. Do we really want udev matching against MODALIAS, and do we really want udev rules to hardcode hid group constants? That's a good question. I don't think the hid group will change in the future and we can guarantee that in the kernel I think. I'd like this idea better if we added a HID_GROUP uevent property with a textual description, or perhaps something a little more specific. This refers back to Jiri's first remark. Adding such a thing is doable, but do we really want/need it :/ The hid group field seems to be used for different types of things. yes, my proposal is definitively a (ugly) hack around the groups which are used to select which hid subdriver we use. An other question which comes to my mind is don't we want logind to assign the hidraw node to the proper client? We may still need to tag the device somehow, but if logind prevents untrusted application to run arbitrary code on the u2f token, that might be a little bit safer than allowing anybody to read/write. Sorry to raise more questions than providing answers. Cheers, Benjamin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Sun, Nov 2, 2014 at 4:40 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 6:34 PM, Andy Lutomirski l...@amacapital.net wrote: On Sun, Nov 2, 2014 at 3:01 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 5:49 PM, Andy Lutomirski l...@amacapital.net wrote: On Sun, Nov 2, 2014 at 2:45 PM, Benjamin Tissoires benjamin.tissoi...@gmail.com wrote: On Sun, Nov 2, 2014 at 4:40 PM, Jiri Kosina jkos...@suse.cz wrote: On Sun, 2 Nov 2014, Jiri Kosina wrote: Alternatively, you can just write udev rule which triggers on HID devices, issues HIDIOCGRDESC ioctl() on the just-created hidraw node, and decides afterwards whether node permissions need to be altered ... right? Just to make myself clear here -- this is basically alternative to your 1st option, but for cases where you want to make yourself independent on sysfs existence (I don't what is the craziness level of setups you are considering). I am a little bit concerned with the user space retrieving the descriptor, parsing it and then deciding how to set the permissions. It's not that it is super complex, but it will duplicate the parsing we already do in the kernel. Wacom tried to do that in their usb driver, and they never managed to fully implement one. I think the HID_GROUP solution is super trivial: - add a match on the U2F input report and set the group to HID_GROUP_U2F (2 lines in hid_scan_input_usage() in hid-core.c) - allow hid-generic to also match HID_GROUP_U2F (1 line in hid-generic.c). Then, the udev rule would be super trivial. I'm confused. What would the user-visible effect of this be? Would the hidraw node still show up? What is user code supposed to match to detect a U2F device or to otherwise set permissions? The only change with what we currently have is that the modalias of the device will be something like MODALIAS=hid:b0003gHID_GROUP_U2Fvp. (replace HID_GROUP_U2F with the proper hex value). So matching against this modalias is trivial, and you can just put the hidraw node rw for users. Do we really want udev matching against MODALIAS, and do we really want udev rules to hardcode hid group constants? That's a good question. I don't think the hid group will change in the future and we can guarantee that in the kernel I think. I'd like this idea better if we added a HID_GROUP uevent property with a textual description, or perhaps something a little more specific. This refers back to Jiri's first remark. Adding such a thing is doable, but do we really want/need it :/ I would tend to think that designing a HID interface for userspace consumption might be a hint that it's the right time to give it a better name than MODALIAS :) --Andy The hid group field seems to be used for different types of things. yes, my proposal is definitively a (ugly) hack around the groups which are used to select which hid subdriver we use. An other question which comes to my mind is don't we want logind to assign the hidraw node to the proper client? We may still need to tag the device somehow, but if logind prevents untrusted application to run arbitrary code on the u2f token, that might be a little bit safer than allowing anybody to read/write. We do want it to be assigned to the proper client. My udev patch (which will almost certainly not be accepted as-is, but it could be fixed up) uses the report_descriptor to set ID_SECURITY_TOKEN=1, which in turn causes an existing rule to set TAG+=uaccess, which causes logind to do its thing. Sorry to raise more questions than providing answers. No problem. --Andy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2 1/2] utf8: intruduce utf8_escape_non_printable
---
src/shared/utf8.c| 87
src/shared/utf8.h| 1 +
src/test/test-utf8.c | 30 ++
3 files changed, 118 insertions(+)
diff --git a/src/shared/utf8.c b/src/shared/utf8.c
index 9353559..5245604 100644
--- a/src/shared/utf8.c
+++ b/src/shared/utf8.c
@@ -210,6 +210,93 @@ char *utf8_escape_invalid(const char *str) {
return p;
}
+char *utf8_escape_non_printable(const char *str) {
+char *p, *s;
+
+assert(str);
+
+p = s = malloc(strlen(str) * 4 + 1);
+if (!p)
+return NULL;
+
+while (*str) {
+int len;
+
+len = utf8_encoded_valid_unichar(str);
+if (len 0) {
+if (utf8_is_printable(str, len)) {
+s = mempcpy(s, str, len);
+str += len;
+} else {
+switch (*str) {
+
+case '\a':
+*(s++) = '\\';
+*(s++) = 'a';
+break;
+case '\b':
+*(s++) = '\\';
+*(s++) = 'b';
+break;
+case '\f':
+*(s++) = '\\';
+*(s++) = 'f';
+break;
+case '\n':
+*(s++) = '\\';
+*(s++) = 'n';
+break;
+case '\r':
+*(s++) = '\\';
+*(s++) = 'r';
+break;
+case '\t':
+*(s++) = '\\';
+*(s++) = 't';
+break;
+case '\v':
+*(s++) = '\\';
+*(s++) = 'v';
+break;
+case '\\':
+*(s++) = '\\';
+*(s++) = '\\';
+break;
+case '':
+*(s++) = '\\';
+*(s++) = '';
+break;
+case '\'':
+*(s++) = '\\';
+*(s++) = '\'';
+break;
+
+default:
+/* For special chars we prefer octal
over
+ * hexadecimal encoding, simply
because glib's
+ * g_strescape() does the same */
+if ((*str ' ') || (*str = 127)) {
+*(s++) = '\\';
+*(s++) = octchar((unsigned
char) *str 6);
+*(s++) = octchar((unsigned
char) *str 3);
+*(s++) = octchar((unsigned
char) *str);
+} else
+*(s++) = *str;
+break;
+}
+str += 1;
+}
+} else {
+s = mempcpy(s, UTF8_REPLACEMENT_CHARACTER,
strlen(UTF8_REPLACEMENT_CHARACTER));
+str += 1;
+}
+}
+
+*s = '\0';
+
+return p;
+}
+
char *ascii_is_valid(const char *str) {
const char *p;
diff --git a/src/shared/utf8.h b/src/shared/utf8.h
index c087995..1fe1a35 100644
--- a/src/shared/utf8.h
+++ b/src/shared/utf8.h
@@ -30,6 +30,7 @@
const char *utf8_is_valid(const char *s) _pure_;
char *ascii_is_valid(const char *s) _pure_;
char *utf8_escape_invalid(const char *s);
+char *utf8_escape_non_printable(const char *str);
bool utf8_is_printable_newline(const char* str, size_t length, bool newline)
_pure_;
_pure_ static inline bool utf8_is_printable(const char* str, size_t length) {
diff --git a/src/test/test-utf8.c b/src/test/test-utf8.c
index b7d988f..fb27fe5 100644
--- a/src/test/test-utf8.c
+++ b/src/test/test-utf8.c
@@ -66,12 +66,42 @@ static void
[systemd-devel] [PATCH v2 2/2] bootchart: escape non printable process name
---
src/bootchart/svg.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/bootchart/svg.c b/src/bootchart/svg.c
index faf377e..e5569e1 100644
--- a/src/bootchart/svg.c
+++ b/src/bootchart/svg.c
@@ -39,6 +39,7 @@
#include svg.h
#include bootchart.h
#include list.h
+#include utf8.h
#define time_to_graph(t) ((t) * arg_scale_x)
#define ps_to_graph(n) ((n) * arg_scale_y)
@@ -1006,12 +1007,15 @@ static void svg_ps_bars(void) {
/* pass 2 - ps boxes */
ps = ps_first;
while ((ps = get_next_ps(ps))) {
-_cleanup_free_ char *enc_name = NULL;
+_cleanup_free_ char *enc_name = NULL, *escaped = NULL;
double endtime;
double starttime;
int t;
-enc_name = xml_comment_encode(ps-name);
+if (!utf8_is_printable(ps-name, strlen(ps-name)))
+escaped = utf8_escape_non_printable(ps-name);
+
+enc_name = xml_comment_encode(escaped ? escaped : ps-name);
if (!enc_name)
continue;
@@ -1100,7 +1104,7 @@ static void svg_ps_bars(void) {
svg( text x=\%.03f\ y=\%.03f\![CDATA[%s]] [%i]tspan
class=\run\%.03fs/tspan %s/text\n,
time_to_graph(w - graph_start) + 5.0,
ps_to_graph(j) + 14.0,
-ps-name,
+escaped ? escaped : ps-name,
ps-pid,
(ps-last-runtime - ps-first-runtime) / 10.0,
arg_show_cgroup ? ps-cgroup : );
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
