Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show SELinux label on failure #216

Merged
merged 1 commit into from
Aug 7, 2024
Merged

Conversation

rhatdan
Copy link
Collaborator

@rhatdan rhatdan commented Jul 31, 2024

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
Copy link
Collaborator Author

rhatdan commented Jul 31, 2024

@kolyshkin @giuseppe @thaJeztah PTAL

@@ -329,7 +329,7 @@ func lSetFileLabel(fpath string, label string) error {
break
}
if err != unix.EINTR {
return &os.PathError{Op: "lsetxattr", Path: fpath, Err: err}
return &os.PathError{Op: "lsetxattr", Path: fpath, Err: fmt.Errorf("label=%s: %v", label, err)}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)}
  			                                                                                         ^

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yikes that is what I meant, good job linter,

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sometimes they're useful! 😂

@thaJeztah
Copy link
Member

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
thaJeztah previously approved these changes Aug 1, 2024
Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

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

Copy link
Collaborator

@kolyshkin kolyshkin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Collaborator Author

rhatdan commented Aug 6, 2024

@kolyshkin Ready to Merge?

kolyshkin
kolyshkin previously approved these changes Aug 7, 2024
Copy link
Collaborator

@kolyshkin kolyshkin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@thaJeztah
Copy link
Member

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).

@@ -329,7 +329,7 @@ func lSetFileLabel(fpath string, label string) error {
break
}
if err != unix.EINTR {
return &os.PathError{Op: "lsetxattr", Path: fpath, Err: err}
return &os.PathError{Op: fmt.Sprintf("lsetxattr(label=%q)", label), Path: fpath, Err: err}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Modified

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.

Signed-off-by: Daniel J Walsh <[email protected]>
Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Sorry for the back-and-forth 🫶

@thaJeztah
Copy link
Member

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

@thaJeztah
Copy link
Member

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)

@thaJeztah thaJeztah merged commit 44b3337 into opencontainers:main Aug 7, 2024
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants