Show SELinux label on failure

[rhatdan]

We are seeing EINVAL errors with container engines setting SELinux labels. It would be helpful to see what Labels the engines are trying to set.

[rhatdan]

@kolyshkin @giuseppe @thaJeztah PTAL

[thaJeztah]

Looks like a linter failed (need to change %v for %w to preserve the original error);

  Error: go-selinux/selinux_linux.go:332:94: non-wrapping format verb for fmt.Errorf. Use `%w` to format errors (errorlint)
  			return &os.PathError{Op: "lsetxattr", Path: fpath, Err: fmt.Errorf("label=%s: %v", label, err)}
  			                                                                                          ^
  Error: go-selinux/selinux_linux.go:351:93: non-wrapping format verb for fmt.Errorf. Use `%w` to format errors (errorlint)
  			return &os.PathError{Op: "setxattr", Path: fpath, Err: fmt.Errorf("label=%s: %v", label, err)}
  			                                                                                         ^

[rhatdan]

Yikes that is what I meant, good job linter,

[thaJeztah]

Sometimes they're useful! 😂

[thaJeztah]

Change otherwise SGTM; error will look something like this when printed;

setxattr /some/path: label=system_u:object_r:bin_t:s0:c3,c4: invalid argument

[thaJeztah]

LGTM

but pinging @kolyshkin if he has any concerns on wrapping the underlying error

[kolyshkin]

My only concern is os.PathError.Err is probably expected to be a raw syscall.Errno. There's some old code which still does something like this:

if pathError, ok := err.(*os.PathError); ok && pathError.Err != unix.EDQUOT && pathError.Err != unix.ENOSPC {

and such code will obviously fail here.

So, maybe we can add extra context into Op instead. Something like

return &os.PathError{Op: "setxattr(label="+label+")", Path...

This might be more bullet-proof as I have yet to see code which checks PathError.Op.

[rhatdan]

@kolyshkin Ready to Merge?

[kolyshkin]

LGTM

[thaJeztah]

So, maybe we can add extra context into Op instead. Something like

return &os.PathError{Op: "setxattr(label="+label+")", Path...

Heh. I was originally considering posting exactly the same as an alternative, then didn't 😂. The checking for a raw syscall.Errno is a good point though (although it's generally not a contract for a non-stdlib package).

[thaJeztah]

Not a hard blocker (and maybe it's why @kolyshkin used string-concatenation in his suggestion); I tend to avoid using %q in formatting more nowadays; it's a great option, but the downside is that the (double) quotes can become a bit noisy if these messages pass some layers, they will be escaped, for example, when passing over an API, or when logging, it may become something like;

error="setxattr(label=\"system_u:object_r:bin_t:s0:c3,c4\") /some/path: invalid argument"

Assuming we don't expect any really horrible strings to be passed as label by someone, %s would probably still work as it would still be wrapped within the (label=<some value>);

error="setxattr(label=system_u:object_r:bin_t:s0:c3,c4) /some/path: invalid argument"

Probably less relevant for this module, but printing the raw value without quotes may also help in cases where (e.g.) a value including quotes was passed (I had some cases where the user expected quotes to be stripped by their shell, but made a mistake).

[rhatdan]

Modified

[thaJeztah]

LGTM!

Sorry for the back-and-forth 🫶

[thaJeztah]

@kolyshkin PTAL; I think this one should be ready to go, but the push dismissed your LGTM

[thaJeztah]

I'll bring this one in; the current implementation is ~ matching @kolyshkin's suggestion (I merely asked him to re-review because we needed a second approval)