Add cryptsetup_status table
#734
Conversation
directionless
force-pushed
the
seph/cryptsetup
branch
from
b69434e
to
61083c8
Compare
|
Testing this out manually, it required that I find the name of a LUKS encrypted device (more annoying that it may sound), but seems to work! |
Yeah, I think that limitation is inherent. And I don't want the table to be clever. |
| tablehelpers.WithLogger(t.logger), | ||
| ) | ||
|
|
||
| if len(requestedNames) == 0 { |
There was a problem hiding this comment.
In other tables, we've also checked that the constraint is =, and that's functionally all this table handles as well.
There was a problem hiding this comment.
Hrm.... You're not wrong, it feels like it would be better to check that the constraint.Operator == table.OperatorEquals But...
- This is using
tablehelpers.GetConstraintsto get a simple iterable. If we wanted to check the Operator, it should be in there. - IIRC osquery doesn't pass anything other than
=to table anyhow.
I'd be willing to think about how to have the helper be more clever about the Operator, since I think (2) is a bug. But I'm not sure what the desired outcome should be.
There was a problem hiding this comment.
- IIRC osquery doesn't pass anything other than = to table anyhow.
Ah I didn't realize that, I thought all constraints were passed through, that feels like either a bug or undesirable limitation to me as well.
There was a problem hiding this comment.
For the record, this isn't necessarily a blocker, but I think consistent handling of the operators is one of those small things that makes the project better overall.
There was a problem hiding this comment.
I agree about consistency. I suspect we should push handling into the helper, and have it return []string, error instead of just []string
This creates a
kolide_cryptsetup_statusas a wrapper over thecryptsetup statuscommand. Similar to #732, it's meant to aid in debugging and understandingThis depends on #731