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

pkg/lockfile: nits #1336

Merged
merged 3 commits into from
Sep 12, 2022
Merged

pkg/lockfile: nits #1336

merged 3 commits into from
Sep 12, 2022

Conversation

kolyshkin
Copy link
Contributor

Fix one issue and a couple of nits in pkg/lockfile. Please see individual commits for details.

Since commit 162a0bf, openLock creates a file even if ro is
set, but the documentation says otherwise.

Since commit 16de6d3, openLock also creates file's parent
directories if needed, but the documentation doesn't say that.

Fix both issues.

Signed-off-by: Kir Kolyshkin <[email protected]>
Since commit 162a0bf, openLock creates a file in case ro
argument is set, but the file is created with 0 permission bits.

Fix this, and unify the file creation logic while at it.

Signed-off-by: Kir Kolyshkin <[email protected]>
unix.Open returns a bare error (like EPERM). This is worked around in
on user, (*lockfile).lock, where we panic, but not in the other user,
createLockerForPath, and as a result such a bare error might be returned
from GetLockfile or GetROLockfile.

Wrap it into os.PathError and remove the workaround from lockfile.lock.

Signed-off-by: Kir Kolyshkin <[email protected]>
)
flags := os.O_RDONLY | unix.O_CLOEXEC | os.O_CREATE
if !ro {
flags |= os.O_RDWR
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This relies on the fact that O_RDONLY value is 0.

Copy link
Collaborator

Choose a reason for hiding this comment

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

That’s

  • Extremely non-obvious to careless users.
  • Not guaranteed to be true, and in fact not true on at least one Go-supported platform right now (though, to be fair, not a platform currently supported by Podman).

Please just do the obviously-correct thing.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

More generally, the assumption is O_RDONLY does not have any bits set that O_RDWR doesn't.

That is true even for zOS (the only Golang platform where O_RDONLY != 0). In zOS, O_RDONLY is 2 and O_RDWR is 3.

Having said that, your code is definitely better as it does not have any such undocumented assumptions.

@rhatdan
Copy link
Member

rhatdan commented Sep 12, 2022

Copy link
Member

@giuseppe giuseppe left a comment

Choose a reason for hiding this comment

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

LGTM

@giuseppe giuseppe merged commit b630454 into containers:main Sep 12, 2022
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