Some new permissions checks

Connected Devices Project Link
#1

The linux version of foxbox now checks to ensure that you belong to the dialout and netdev groups, and if you don’t it will fail with a fatal message like this:

thread '<main>' panicked at 'Not a member of the netdev group.', src/main.rs:178
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: Process didn't exit successfully: `target/debug/foxbox` (exit code: 101)
#2

Just wondering: why these groups exactly ? And why a fatal error ?
If this is because this is needed to operate a zwave stick, this is
especially why I did these PR:
https://github.com/fxbox/openzwave-adapter/pull/23 and
https://github.com/fxbox/openzwave-stateful-rust/pull/17. And we agreed
to make it non-fatal because not everybody wants to use a zwave adapter.

#3

I can say only for “netdev” group:

  1. User should be a member of this group to be able to change host local name; I can’t say how critical it’s though. @sgiles , @fabrice what should happen to the box if we can’t change its name?
  2. Current multicast_dns crate (the one that is responsible for local name change) will panic if user is not a member of “netdev” group anyway. And yes, it’s bad, and I’m going to fix this in [1] once I have some time.

[1] https://github.com/fxbox/multicast-dns/issues/6

#4

is it possible to detect this issue differently ? Because I’m sure
different Linux distributions will have different opinions about which
groups are needed. Moreover Linux or Windows don’t care about groups and
might still have the issue for other reasons.

#5

I got some issues on Arch. I’m making a patch to verify the user belongs to one of the list of groups, instead of just one.

#6

Wondering if these group names should be configurable…

Currently I use my emulator “device” with openzwave adapter via: --config ‘openzwave;device;/tmp/ttyS0’.

Can we do the same for groups: like --config ‘groups;mdns;netdev’?

#7

I think we should just remove this check, it’s not useful anymore now
that I landed the check that the openzwave device is actually readable.

But I’d like to wait before dhylands wakes up :slight_smile:

#8

Well, it makes sense for the optional things like openzwave adapter :slightly_smiling: But I’m still not sure if box works as expected without properly set local name though (especially when more than one box is on the same network).

#9

https://github.com/fxbox/foxbox/pull/402

Even though I made this follow up patch, I agree with @julienw: checking if a device readable or a hostname writable sounds more future proof than listing every group somebody should be in.

#10

The box will work “correctly” with the nUPNP registration scheme we have (registration server and local. domains). The local hostname is independent of this.

The only thing different from my point of view is: whatever hostname you set, a self signed certificate is created and added to the CertificateManager - that’s pretty much it, you’d then be able to securely connect to using that local hostname given you add an exception for the self signed cert.

You should also get a ‘foxbox.local’ cert by default (the “box cert”), which acts as your client certificate for making requests to the APIs (and provides the fingerprint).

#11

The issue I was running into was this:
https://github.com/fxbox/foxbox/issues/363

And we decided that the best way to address this is to have better error
messages (rather than the panic).
So I backed out the permissions check for now.