udev-rules for my FST-01 gnuk security token

udev-rules for my FST-01 gnuk security token

[Arun Isaac]

I am trying to get my FST-01 gnuk security token working on
GuixSD. According to their documentation
(https://www.fsij.org/doc-gnuk/udev-rules.html), I need to add a custom
udev-rule. I am trying to use the configuration shown below to achieve
the same. But, I don't see any file by the name "60-gnupg.rules" created
in my /run/current-system/profile/lib/udev/rules.d/. Am I doing
something wrong or is my expectation incorrect? Has anyone successfully
used a FST-01 gnuk security token in GuixSD?

(use-modules (gnu))

(define %gnuk-udev-rule
  (udev-rule
   "60-gnupg.rules"
   "ATTR{idVendor}==\"234b\", ATTR{idProduct}==\"0000\", ENV{ID_SMARTCARD_READER}=\"1\", ENV{ID_SMARTCARD_READER_DRIVER}=\"gnupg\""))

(operating-system
 (host-name "adamantium")
 (timezone "Asia/Kolkata")
 (locale "en_US.utf8")
 (bootloader (bootloader-configuration
	      (bootloader grub-bootloader)
	      (target "/dev/sda")))
 (file-systems (cons (file-system
		      (device "my-root")
		      (mount-point "/")
		      (type "ext4"))
		     %base-file-systems))
 (users %base-user-accounts)
 (packages %base-packages)
 (services
  (modify-services %base-services
		   (udev-service-type
		    config =>
		    (udev-configuration
		     (inherit config)
		     (rules
		      (append (udev-configuration-rules config)
			      (list %gnuk-udev-rule))))))))

Re: udev-rules for my FST-01 gnuk security token

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

Arun Isaac <arunisaac@systemreboot.net> writes:

> I am trying to get my FST-01 gnuk security token working on
> GuixSD. According to their documentation
> (https://www.fsij.org/doc-gnuk/udev-rules.html), I need to add a custom
> udev-rule. I am trying to use the configuration shown below to achieve
> the same. But, I don't see any file by the name "60-gnupg.rules" created
> in my /run/current-system/profile/lib/udev/rules.d/. Am I doing
> something wrong or is my expectation incorrect? Has anyone successfully
> used a FST-01 gnuk security token in GuixSD?
>
> (use-modules (gnu))
>
> (define %gnuk-udev-rule
>   (udev-rule
>    "60-gnupg.rules"
>    "ATTR{idVendor}==\"234b\", ATTR{idProduct}==\"0000\", ENV{ID_SMARTCARD_READER}=\"1\", ENV{ID_SMARTCARD_READER_DRIVER}=\"gnupg\""))
>
> (operating-system
>  (host-name "adamantium")
>  (timezone "Asia/Kolkata")
>  (locale "en_US.utf8")
>  (bootloader (bootloader-configuration
> 	      (bootloader grub-bootloader)
> 	      (target "/dev/sda")))
>  (file-systems (cons (file-system
> 		      (device "my-root")
> 		      (mount-point "/")
> 		      (type "ext4"))
> 		     %base-file-systems))
>  (users %base-user-accounts)
>  (packages %base-packages)
>  (services
>   (modify-services %base-services
> 		   (udev-service-type
> 		    config =>
> 		    (udev-configuration
> 		     (inherit config)
> 		     (rules
> 		      (append (udev-configuration-rules config)
> 			      (list %gnuk-udev-rule))))))))
>

I was able to reproduce your issue by using "guix system build" and
inspecting the profile of the built system.  It's missing the udev rule
you added, like you said.  What's more concerning is the fact that it's
missing the file "90-kvm.rules", which are supposed to be part of the
default rules included in our udev service (see gnu/services/base.scm).

Maybe it's a bug.  Could you open a bug report by emailing bug-guix@?

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: udev-rules for my FST-01 gnuk security token

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 5163 bytes --]

Chris Marusich <cmmarusich@gmail.com> writes:

> Arun Isaac <arunisaac@systemreboot.net> writes:
>
>> I am trying to get my FST-01 gnuk security token working on
>> GuixSD. According to their documentation
>> (https://www.fsij.org/doc-gnuk/udev-rules.html), I need to add a custom
>> udev-rule. I am trying to use the configuration shown below to achieve
>> the same. But, I don't see any file by the name "60-gnupg.rules" created
>> in my /run/current-system/profile/lib/udev/rules.d/. Am I doing
>> something wrong or is my expectation incorrect? Has anyone successfully
>> used a FST-01 gnuk security token in GuixSD?
>>
>> (use-modules (gnu))
>>
>> (define %gnuk-udev-rule
>>   (udev-rule
>>    "60-gnupg.rules"
>>    "ATTR{idVendor}==\"234b\", ATTR{idProduct}==\"0000\", ENV{ID_SMARTCARD_READER}=\"1\", ENV{ID_SMARTCARD_READER_DRIVER}=\"gnupg\""))
>>
>> (operating-system
>>  (host-name "adamantium")
>>  (timezone "Asia/Kolkata")
>>  (locale "en_US.utf8")
>>  (bootloader (bootloader-configuration
>> 	      (bootloader grub-bootloader)
>> 	      (target "/dev/sda")))
>>  (file-systems (cons (file-system
>> 		      (device "my-root")
>> 		      (mount-point "/")
>> 		      (type "ext4"))
>> 		     %base-file-systems))
>>  (users %base-user-accounts)
>>  (packages %base-packages)
>>  (services
>>   (modify-services %base-services
>> 		   (udev-service-type
>> 		    config =>
>> 		    (udev-configuration
>> 		     (inherit config)
>> 		     (rules
>> 		      (append (udev-configuration-rules config)
>> 			      (list %gnuk-udev-rule))))))))
>>
>
> I was able to reproduce your issue by using "guix system build" and
> inspecting the profile of the built system.  It's missing the udev rule
> you added, like you said.  What's more concerning is the fact that it's
> missing the file "90-kvm.rules", which are supposed to be part of the
> default rules included in our udev service (see gnu/services/base.scm).
>
> Maybe it's a bug.  Could you open a bug report by emailing bug-guix@?

I understand what's happening, now.  It isn't a bug.  In short, your
rules are being used.  It's just a little confusing because Guix starts
udevd in a way that causes it to use a specific configuration directory
in the store, which is built to contain the union of all the specified
rules.  I'll explain more below.

If you run a VM with your OS configuration (via "guix system vm
my-os.scm"), you can follow along.  You have the following directories:

/run/current-system/profile/lib/udev/rules.d
/run/current-system/profile/etc/udev/rules.d

These come from the eudev package, as shown here (store item hash
abbreviated, since I cannot easily copy/paste from QEMU at the moment):

--8<---------------cut here---------------start------------->8---
# readlink /run/current-system/profile/lib/udev/rules.d
/gnu/store/...hv9c-eudev-3.2.5/etc/udev
# readlink /run/current-system/profile/etc/udev/rules.d
/gnu/store/...hv9c-eudev-3.2.5/etc/udev
--8<---------------cut here---------------end--------------->8---

However, udevd doesn't use these directories.  Examine its arguments:

--8<---------------cut here---------------start------------->8---
# ps -wwfe | grep udevd
root       251     1  0 10:12 ?         00:00:00 /gnu/store/...hv9c-eudev-3.2.5/sbin/udevd
--8<---------------cut here---------------end--------------->8---

It doesn't have any arguments.  In fact, we configure it via environment
variables.  Check them:

--8<---------------cut here---------------start------------->8---
# cat /proc/251/environ | tr '\000' '\n'
...
UDEV_CONFIG_FILE=/gnu/store/...f32r-udev.conf
EUDEV_RULES_DIRECTORY=/gnu/store/...cx44-udev-rules/lib/udev/rules.d
--8<---------------cut here---------------end--------------->8---

If you check that rules.d directory, you'll find your rules:

--8<---------------cut here---------------start------------->8---
# ls /gnu/store/...cx44-udev-rules/lib/udev/rules.d | grep gnupg
60-gnupg.rules
--8<---------------cut here---------------end--------------->8---

So, all is well.  If you run tools like udevadm to test the rules, you
should be able to confirm that your custom rules are being used.  By the
way, the kvm rules are here, too (thank goodness!):

--8<---------------cut here---------------start------------->8---
# ls /gnu/store/...cx44-udev-rules/lib/udev/rules.d | grep kvm
90-kvm.rules
--8<---------------cut here---------------end--------------->8---

But why does your system have rules.d directories in
/run/current/system/profile, if udevd isn't using them?  It's because
eudev happens to be included in the %base-packages (defined in (gnu
system)), which causes eudev (and its rules.d directories) to be
installed into your system profile.  The purpose of installing eudev
into the system profile is probably not to add these rules.d
directories, but rather to make things like the usual tools (e.g.,
udevadm) available to all users.

For more details on how all of this fits together, check out
gnu/services/base.scm and gnu/system.scm in the Guix source.  I hope
that helps!

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: udev-rules for my FST-01 gnuk security token

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

Thanks for this walkthrough, Chris, very useful!

I guess we should document this a bit more, what do you think?

If /run/current/system/profile/lib/udev/rules.d is not used, couldn't we remove
it to avoid confusion?

Then mention the

--8<---------------cut here---------------start------------->8---
# cat /proc/251/environ | tr '\000' '\n'
...
UDEV_CONFIG_FILE=/gnu/store/...f32r-udev.conf
EUDEV_RULES_DIRECTORY=/gnu/store/...cx44-udev-rules/lib/udev/rules.d
--8<---------------cut here---------------end--------------->8---

trick somewhere to help users find the rules directory.
-- 
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: udev-rules for my FST-01 gnuk security token

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 2540 bytes --]

Pierre Neidhardt <ambrevar@gmail.com> writes:

> Thanks for this walkthrough, Chris, very useful!

I'm glad you liked it!  I enjoy sharing what I know, although often I
feel like it isn't enough.  :-)

> I guess we should document this a bit more, what do you think?

I'm sympathetic, but I don't think we need to add documentation.  Here's
why.

This behavior is not specific to the udev service.  Because we use Guix
heavily in GuixSD for as many aspects of system configuration as
possible, lots of services are configured to point to store items.  It's
the natural place to store (immutable) configuration.

It was just particularly confusing in this case because of the spurious
rules.d directories in the system profile. But I think the description
of the udev service is clear in our manual ((guix) Base Services).  It
says that the udev service is extended by using the udev-rule procedure,
or via packages that deposit udev rules at the expected output path.  I
can't think of a way to make it better.

Because GuixSD is a declarative system, it isn't necessary to modify
system files in-place.  In other distros, which are not declarative,
it's normal to mutate system files to shape the system to your needs.
With that in mind, hopefully it is less surprising that the services
GuixSD uses rely on (immutable) files in the store.

> If /run/current/system/profile/lib/udev/rules.d is not used, couldn't
>we remove
> it to avoid confusion?

I'd like to, but unfortunately it isn't quite so simple.  The rules.d
directory is present there because eudev is in the system profile.  The
reason eudev is there is probably to provide tools like udevadm.  It
might be possible to devise a clever way to arrange for the rules.d
directory to be left out of the system profile without breaking the way
that the udev service also collects rules from its extensions, but I'm
not sure it's worth the effort here.

If someone knows otherwise, I'd love to know.

> Then mention the
>
> # cat /proc/251/environ | tr '\000' '\n'
> ...
> UDEV_CONFIG_FILE=/gnu/store/...f32r-udev.conf
> EUDEV_RULES_DIRECTORY=/gnu/store/...cx44-udev-rules/lib/udev/rules.d
>
> trick somewhere to help users find the rules directory.

This specific trick can be used in a lot of situations.  I don't think
it should be called out for this specific case in our manual, but I
think it might be good content for a troubleshooting guide or a FAQ or
something.  We do need more of that sort of stuff.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: udev-rules for my FST-01 gnuk security token

[Arun Isaac]

Thank you for your very detailed response, Chris! That does clear up my
confusion with udev. I am yet to get my FST-01 gnuk security token
working. But, that must be a problem elsewhere, and I'll figure it
out. If I need any further help, I'll ask on this list.

Thanks!

Re: udev-rules for my FST-01 gnuk security token

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 241 bytes --]

I have no clue if it's related to your case, but for my Nitrokey there was some
special setup as detailed in this thread:

	https://lists.gnu.org/archive/html/help-guix/2018-05/msg00187.html

Maybe that helps.

-- 
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: udev-rules for my FST-01 gnuk security token

[Arun Isaac]

> I have no clue if it's related to your case, but for my Nitrokey there was some
> special setup as detailed in this thread:
>
> 	https://lists.gnu.org/archive/html/help-guix/2018-05/msg00187.html

Thanks for the link. I have the exact same problem. The Nitrokey Start
and the FST-01 gnuk token are very similar devices. So, probably, the
solution is also similar. I will find out and let you know.

Re: udev-rules for my FST-01 gnuk security token

[Arun Isaac]

> I have no clue if it's related to your case, but for my Nitrokey there was some
> special setup as detailed in this thread:
>
> 	https://lists.gnu.org/archive/html/help-guix/2018-05/msg00187.html

The same solution works! Install pcsc-lite and ccid into user profile,
and run the following.

sudo ln -s ~/.guix-profile/pcsc /var/lib/pcsc
sudo pcscd -f

After these, `gpg --card-status` works as expected. :-)

We do need a service for this. I'll write one if nobody beats me to it.

Re: udev-rules for my FST-01 gnuk security token

[Arun Isaac]

> We do need a service for this. I'll write one if nobody beats me to
> it.

I have created a Guix service for pcscd.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32358

It looks like the udev rules were completely unnecessary for my gnuk
token. Running the pcscd daemon alone was sufficient. Perhaps, it's the
same for your nitrokey.