search

fdo-rs / fido-device-onboard-rs

An implementation of the FIDO Device Onboard (FDO) spec written in Rust.
BSD 3-Clause "New" or "Revised" License
58 stars 33 forks source link

docs(howto): removed /var/lib/fdo requisite from serviceinfo-api-server #554

Open tym2k1 opened 11 months ago

tym2k1 commented 11 months ago

The HOWTO.md document mentions that files parsed through the serviceinfo-api-server should have their source_path variable located under the /var/lib/fdo directory. However, during onboarding, the process seems to work correctly even when the source_path is set to a different directory. Additionally, the code in serviceinfo-api-server/src/main.rs does not enforce this directory requirement.

tym2k1 commented 11 months ago

Fixed the name of the commit docs(howto): removed /var/lib/fdo requisite from serverinfo-api-server -> docs(howto): removed /var/lib/fdo requisite from serviceinfo-api-server

nullr0ute commented 11 months ago

Having it elsewhere may cause issues with SELinux and from a support PoV I would prefer us to have a default location here.

7flying commented 11 months ago

Having it elsewhere may cause issues with SELinux and from a support PoV I would prefer us to have a default location here.

@nullr0ute agreed, but the docs are also not completely right about this. We can either explain this better on the docs or enforce the usage of that default location on code.

tym2k1 commented 11 months ago

I agree. My main concern is clarity for developers who are trying to integrate this service into their environments. If there's potential for issues when deviating from the /var/lib/fdo directory, it might be beneficial to have a more explicit warning or note in the HOWTO.md. From my understanding enforcing the use of '/var/lib/fdo' would force developers to contenerize this service which is a good practice but it might make the project less flexible for some uses.

tym2k1 commented 11 months ago

Thank you for the fast response by the way :)

nullr0ute commented 11 months ago

From my understanding enforcing the use of '/var/lib/fdo' would force developers to contenerize this service which is a good practice but it might make the project less flexible for some uses.

I don't follow this point about containerisation, the /var/lib directory structure is used for services data for a very long time irrespective of containerisation or not.

tym2k1 commented 11 months ago

I see your point regarding the /var/lib convention. What I was trying to convey is that there might be scenarios where developers run the app as a standalone process (as me right now during testing), rather than a systemd service. Enforcing the use of /var/lib could complicate matters in these cases. My mention of containerization was an offshoot of this thought. Thank you for bringing up the systemd context; it's essential to consider both use-cases.