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

ability to install suid/fcaps binaries with non-root ownership #462

Closed
cgwalters opened this issue Sep 14, 2016 · 7 comments
Closed

ability to install suid/fcaps binaries with non-root ownership #462

cgwalters opened this issue Sep 14, 2016 · 7 comments

Comments

@cgwalters
Copy link
Member

e.g. kubernetes-master. See #432

@dustymabe
Copy link
Member

hey @cgwalters, how techincal of an issue is this? is the solution straightforward?

@jasonbrooks
Copy link
Contributor

I tested a version of the f25 kubernetes package where the apiserver binary was owned by root and I got this error nevertheless complaining of non-root ownership:

error: Unpacking kubernetes-master-1.4.5-6.fc25.x86_64: Non-root ownership currently unsupported: path "/usr/bin/kube-apiserver" marked as root:root)

@cgwalters
Copy link
Member Author

@dustymabe It's intertwined with #49

Also have to work on better test coverage first.

@jasonbrooks Oh that should be an easy fix, will do.

@cgwalters
Copy link
Member Author

@jasonbrooks #532

@jasonbrooks
Copy link
Contributor

I tested this by making a version of kubernetes-master w/ a root-owned kube-apiserver, and I was able to install it. The issue remains for the non-modified kube-apiserver w/ its "kube" ownership.

@jlebon
Copy link
Member

jlebon commented Jan 3, 2017

It looks like even if we switch over to systemd-sysusers here (either through a new change proposal, or through manually synthesizing entries as mentioned in #49), we'll still have some complexity in package layering.

The "easy" way out here would be to run the %pre before unpacking the files, so that we can grab the new ids.

Alternatively, we can canonicalize unpacked files to root:root, and during assembly, break hardlinks and set the right ids & caps before the final commit. In that case, the pkglayer cache repo acts more as a convenient way to store RPMs rather than a hardlink farm (though regular files are still hardlinked). Doing the final id & cap setting later might also be considered safer anyway wrt https://bugzilla.gnome.org/show_bug.cgi?id=722984.

@cgwalters
Copy link
Member Author

Breaking links just for suid/fcaps sounds sanest to me. Long term, we want to get away from suid binaries, so eventually it'll be equivalent.

jlebon added a commit to jlebon/rpm-ostree that referenced this issue Jan 6, 2017
We lift the restriction from the unpacker on non-root owners. The
unpacker now imports all files as root:root with no file caps.

We split the running of rpm scripts between %pre and %post/posttrans as
two different stages. During assembly, we first run the %pre scripts,
collect users and groups, then chown and set file caps as needed (and
then finally run the %post scripts).

Closes: coreos#462
jlebon added a commit to jlebon/rpm-ostree that referenced this issue Jan 6, 2017
We lift the restriction from the unpacker on non-root owners. The
unpacker now imports all files as root:root.

We split the running of rpm scripts between %pre and %post/posttrans as
two different stages. During assembly, we first run the %pre scripts,
collect users and groups, then chown as needed (and then finally run the
%post scripts).

Closes: coreos#462
jlebon added a commit to jlebon/rpm-ostree that referenced this issue Jan 6, 2017
We lift the restriction from the unpacker on non-root owners. The
unpacker now imports all files as root:root.

We split the running of rpm scripts between %pre and %post/posttrans as
two different stages. During assembly, we first run the %pre scripts,
collect users and groups, then chown as needed (and then finally run the
%post scripts).

Closes: coreos#462
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants