feat: machined, talosctl: enable listing labels

[dsseng]

trafficstars

Pull Request

What? (description)

Extended attributes are useful for SELinux labels and more

Tested in Docker on a SELinux-enforcing host (openSUSE)

Why? (reasoning)

Fixes #1542

Acceptance

Please use the following checklist:

• [x] you linked an issue (if applicable)
• [ ] you included tests (if applicable)
• [ ] you ran conformance (make conformance)
• [x] you formatted your code (make fmt)
• [x] you linted your code (make lint)
• [x] you generated documentation (make docs)
• [ ] you ran unit-tests (make unit-tests)

See make help for a description of the available targets.

[dsseng]

Will have to fix the CI...

[dsseng]

IMA/EVM and AppArmor use them as well. IMA/EVM has been requested afaik, and we should consider it someday

[smira]

IMA/EVM and AppArmor use them as well. IMA/EVM has been requested afaik, and we should consider it someday

So my 2 cents:

• it'd be easier to just have list -l show SELinux labels as a column vs. a separate output for xattrs
• how resource intensive is reading xattrs for every file even if we never use them?

[dsseng]

it'd be easier to just have list -l show SELinux labels as a column vs. a separate output for xattrs

Well, if we only consider SELinux, yes. We could also just avoid listing those and directly get security.selinux

how resource intensive is reading xattrs for every file even if we never use them?

According to source there should be 1 syscall to list and 1 syscall per xattr to read. Anyway these API calls are not expected to be ran frequently.

[smira]

it also allocates a buffer for each xattr read.

what I mean is that make xattr reading optional, enable only if we list with --long, and for now in talosctl show just selinux label to make it less of a mess

[dsseng]

Alright, will do

[dsseng]

Formatting seems a bit off (` added to make sure those aren't extra long strings).

[dsseng]

Will reword after review when merging

[dsseng]

/m

[dsseng]

/m