-
Notifications
You must be signed in to change notification settings - Fork 384
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
move keyctl to internal & func remove auth from keyring #683
Conversation
@mtrmac @vrothberg PTAL 🙂 |
8147289
to
0ec0452
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a very quick first look
pkg/keyctl/key.go
Outdated
@@ -62,3 +62,12 @@ func (k *Key) Unlink() error { | |||
_, err := unix.KeyctlInt(unix.KEYCTL_UNLINK, int(k.id), int(k.ring), 0, 0) | |||
return err | |||
} | |||
|
|||
// Describe returns a string describing the attributes of a specified key | |||
func Describe(kID ID) (string, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No more public functions in this subpackage, please; we don’t want to maintain it as a stable public API. Make them private in pkg/docker/config
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we could (should?) move this package into ./internal
before the next major bump?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why Unlink() can stay in pkg/keyctl/key.go but not Describe(kID ID)..
I think move keyctk package to ./internal
is better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The pkg/keyctl
package was present in a release, so we can’t remove it, or any public functions/methods/types in it, without a major version bump.
Still, it’s not something users are expected to look for in c/image, and we don’t really want to maintain or enhance it for such hypothetical external users — after all, it’s just a pretty small façade for golang.org/x/sys/unix
now.
#676 has already marked pkg/keyctl
as deprecated: at the time, all callers could use either golang.org/x/sys/unix
or github.com/jsipprell/keyctl
without involving c/image.
This is a bit less true now that ReadUserKeyring
seems to have no direct equivalent in either of those packages; still, c/image is not the obvious place to maintain that as a public utility.
Having the new code directly in pkg/docker/config
(or maybe pkg/docker/config/internal
or something like pkg/docker/config/internal/keyring
) would work well enough, I think; nothing else in the repo needs to care.
Before v4.0.0 we can then either move the current pkg/keyctl
to that same location, or just discard it replace its users with direct calls to golang.org/x/sys/unix
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added the new code to pkg/docker/config_linux.go, should I move it to pkg/docker/config.go?
Do I need to add test readUserKeyring
in pkg/docker/config/config_test.go?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
removeAllAuthFromKernelKeyring
is Linux-specific, so it needs to be in a *_linux.go
file (or a differently-named file that uses an explicit build tag).
Both config_linux.go
and a separate keyring_linux.go
would be fine with me.
If unit tests exist, having them (again, in a Linux-specific file) in the package would be nice, sure. (If they don’t, it’s not quite blocking the PR … but this is not quite trivial code, so tests would be nice.)
0ec0452
to
1595019
Compare
93718ea
to
e75f429
Compare
pkg/docker/config/config_linux.go
Outdated
} | ||
|
||
// readUserKeyring reads user keyring and returns slice of key id(key_serial_t) representing the IDs of all the keys that are linked to it | ||
func readUserKeyring() ([]int32, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(A fair amount about this code could be simplified, OTOH I suppose it’s somewhat useful that that it is exactly the same as the loop in Key.Get().)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can export the id of Key struct
and set a Key variable with id KEY_SPEC_USER_KEYRING
to call Key.Get() and remove readUserKeyring()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can export the id of
Key struct
and set a Key variable with idKEY_SPEC_USER_KEYRING
to call Key.Get() and removereadUserKeyring()
Does this sound better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the code as is good enough; not worth adding extra public interfaces to pkg/keyring
for me, at least.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@QiWang19 Could you still revert the recent change, keeping the read loop in here so that we don’t make the Key.Id
value public?
@@ -14,3 +14,7 @@ func deleteAuthFromKernelKeyring(registry string) error { | |||
func setAuthToKernelKeyring(registry, username, password string) error { | |||
return ErrNotSupported | |||
} | |||
|
|||
func removeAllAuthFromKernelKeyring() error { | |||
return ErrNotSupported |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Non-blocking: This will cause pointless debug logs about failures on non-Linux platforms. OTOH it is consistent with the others, so it would be better to clean this up in a separate PR.)
e75f429
to
cacda0d
Compare
Is this ready to merge then? |
cacda0d
to
96fd441
Compare
revert the code to not export Key.id and create a PR in libpod to test if can pass the CI containers/podman#3860 |
2f92651
to
55d4042
Compare
@mtrmac @vrothberg PTAL |
@mtrmac @vrothberg Is this ready to merge. We need to finish this up and get back to enabling the kernel keyring support. |
55d4042
to
8e1c9e9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a minor nit (absolutely non-blocking). I think that most of the low-level code should go into pkg/keyctl
to avoid scattering the low-level code over multiple packages. I would also love to see some tests for it. We already regressed in libpod on it, so I'd prefer to test as early as possible.
pkg/docker/config/config_linux.go
Outdated
if err != nil { | ||
return errors.Wrapf(err, "error unlinking key %d", kID) | ||
} | ||
logrus.Debugf("unlink key %d:%s", kID, keyAttr) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/unlink/unlinked/?
Sorry for the very late reply. I must have missed that going through my mails. |
which part of the low level code? Some code was not added to keyctl because The pkg/keyctl package was present in a release, so we can’t remove it, or any public functions/methods/types in it, without a major version bump.#683 (comment) |
The code of ...
It's dealing with keyring details that I think should be in the
I am not asking to remove the |
hmm, there's comment mentioned no more public method in keyctl
|
It does not make sense to me to scatter code. Either we use #563 will entail a major version bump as well - if that was the motivation for scattering. |
8e1c9e9
to
71d6976
Compare
moved syscalls KEYCTL_READ, KEYCTL_DESCRIBE to keyctl. |
We have no ambition to create a general keyring abstraction, and no interest in taking the time to design a good stable long-term API for that; so, nothing about the keyring should be a part of the public API of c/image. (OTOH c/image could link to some other external package that is exists to make the keyring access easy — but then the one we chose ended up being more trouble than benefit.) So, per #683 (comment), I’d strongly prefer either an internal subpackage, or just separate files in WRT scattering the code between
|
I think we should move it. |
71d6976
to
5f88be2
Compare
PTAL @vrothberg @mtrmac |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks @QiWang19!
Could you rebase?
5f88be2
to
0c82bbe
Compare
Move pkg/keyctl to internal/pkg/keyctl. Add method removeAllAuthFromKeyring. Get key describes from keyring using KEYCTL_READ and KEYCTL_DESCRIBE, and remove them from keyring if the decription has prefix 'container-registry-login:'. Signed-off-by: Qi Wang <[email protected]>
0c82bbe
to
d033863
Compare
LGTM |
Move pkg/keyctl to internal/pkg/keyctl.
Add method removeAllAuthFromKeyring.
Get key describes from keyring using KEYCTL_READ and KEYCTL_DESCRIBE, and remove them from keyring if the description has prefix 'container-registry-login:'.
Signed-off-by: Qi Wang [email protected]