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

checkpath: use O_PATH when available #244

Merged
merged 1 commit into from Dec 2, 2018

Conversation

floppym
Copy link
Contributor

@floppym floppym commented Oct 3, 2018

This avoids opening directories/files with read permission, which is
sometimes rejected by selinux policy.

Bug: https://bugs.gentoo.org/667122

static int fchmod_opath(int fd, mode_t mode)
{
#ifdef O_PATH
char path[50];
Copy link

Choose a reason for hiding this comment

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

path[50] seems arbitrary, why not something like https://github.com/systemd/systemd/blob/master/src/tmpfiles/tmpfiles.c (e.g. DECIMAL_STR_MAX() macro)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did not want to directly copy/paste code from systemd for copyright reasons.

Copy link
Contributor

Choose a reason for hiding this comment

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

It appears the number of FDs is limited to unsigned long in the kernel, so the max the path could be is 24 chars (then 25 with the NULL). so its fine as is yeah

Copy link
Contributor

Choose a reason for hiding this comment

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

It looks like the posix version of this, which Linux doesn't implement, is O_SEARCH, but I do not have a way to test [1] [2].

Instead of using a hard-coded array of characters for the paths, I would include helpers.h and use xasprintf() to create them.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html
[2] https://stackoverflow.com/questions/44159325/why-is-there-no-o-search-flag-under-linux-for-open-function

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We know the size of the string cannot exceed 26 bytes on a system with 32-bit ints, or 35 bytes if ints are 64-bits. 50 bytes was just a ballpark overestimate.

A fixed-size buffer allocated on the stack is more efficient than calling malloc and free.

Copy link
Member

Choose a reason for hiding this comment

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

sounds reasonable. can you add a short comment above the static buffer explaining ?

@floppym
Copy link
Contributor Author

floppym commented Oct 7, 2018

I pushed a new version that uses fchownat() with AT_EMPTY_PATH as a replacement for the broken fchown() function on Linux.

static int fchmod_opath(int fd, mode_t mode)
{
#ifdef O_PATH
char path[50];
Copy link
Member

Choose a reason for hiding this comment

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

sounds reasonable. can you add a short comment above the static buffer explaining ?

@@ -69,6 +70,37 @@ const char * const longopts_help[] = {
};
const char *usagestring = NULL;

/*
* Work around limitation in Linux when calling fchmod() on a file
Copy link
Member

Choose a reason for hiding this comment

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

can you add a bit more detail (and perhaps include a link to man7.org) here ? i know what limitation you're referring to, but for people who aren't into these low level esoteric details, this comment is just mysterious.

This avoids opening directories/files with read permission, which is
sometimes rejected by selinux policy.

Bug: https://bugs.gentoo.org/667122
@floppym
Copy link
Contributor Author

floppym commented Dec 2, 2018

New version pushed with more detailed comments.

@vapier vapier merged commit 2af0ced into OpenRC:master Dec 2, 2018
@vapier
Copy link
Member

vapier commented Dec 2, 2018

thanks!

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.

None yet

5 participants