store: use group permissions about rkt HOT 13 CLOSED

I'm not sure I understand this. Do you mean being able to download the image as a user so we can later run it without Internet access (zero outbound connections)?

What's the use case?

from rkt.

launch the container with zero outbound connections

Is this related to appc/spec#73 (the part that talks about manual import and "offline" mode)?

from rkt.

What's the use case?

The local CAS should be shareable among multiple local users on the system - there's no need for access to be restricted to the superuser or any particular user. So, user A should be able to download an image into the CAS and then user B should be able to use that same image from the cache without re-downloading it.

from rkt.

OK. I'd like to work on this.

I have some questions:

• In order to do this, we need a rocket group so that users belonging to this group can fetch images to /var/lib/rkt/cas. Is that correct or should any user be able to fetch images?
• Once an image is in the local CAS, what about running it? Only root should be able to run it or can members of the rocket group also run it? Is this in the scope of this issue? [Edit: Just realized that systemd-nspawn requires root]

from rkt.

In order to do this, we need a rocket group so that users belonging to this group can fetch images to /var/lib/rkt/cas. Is that correct or should any user be able to fetch images?

Yeah, the simplest way to go here is probably to just define a rocket Unix group and open write permissions up for it. Then administrators can control access to the CAS as strictly (e.g. add no users to the group) or openly (e.g. add all local users to the group) as they want.

Once an image is in the local CAS, what about running it? Only root should be able to run it or can members of the rocket group also run it? Is this in the scope of this issue? [Edit: Just realized that systemd-nspawn requires root]

While execution is restricted to root (due to systemd-nspawn), I would expect the reading of the image files themselves to either be open to the world or restricted to the same group that's capable or writing.

It would be nice if these could both be somewhat configurable but I am not sure we want to introduce a configuration file to rkt just yet, @philips ?

from rkt.

It would be nice if these could both be somewhat configurable but I am not sure we want to introduce a configuration file to rkt just yet, @philips ?

Let me rephrase slightly: we will inevitably have a configuration file at some point (e.g. #194) but I am not quite convinced it's necessary to make this particular parameter configurable yet; relying on good old Unix group perms seems like a fine approach to me for now.

from rkt.

I wrote a proof of concept (endocode@3c6f623 that adds a new command setup which creates the necessary directories in /var/lib/rkt/with the right permissions. This needs to be run as root and, after doing that, any user belonging to the rocket group can fetch and run images (running will not work because of systemd-nspawn).

However, I don't think this is the right solution.

• I will only work on systems that use /etc/group
• I think this directory creation should be handled by either some sort of make install or by a distro package

The way Rocket is described now in the README.md suggests that it's meant to be used directly as a binary, so no make install or packaging is considered. What are your thoughts on this?

Maybe we should just mention in the README.md or in the Documentation something like "An admin should create these directories with those permissions..."

from rkt.

The way Rocket is described now in the README.md suggests that it's meant to be used directly as a binary, so no make install or packaging is considered. What are your thoughts on this?

This was really just for convenience to make initial versions of rocket easy to obtain and run - having a single, self-contained artefact that people can download and run is handy.

I definitely anticipate it being split out into separate components and then integrated with different (OS) distribution packaging systems, though (see for example #265, #173), so requirements like creating the directory in advance with appropriate permissions makes total sense to me.

from rkt.

Alright, I just wrote a comment mentioning this to https://bugzilla.redhat.com/show_bug.cgi?id=1169966

from rkt.

@iaguis I think having this rkt install subcommand would be helpful for many people at this early stage of the project, we can make it easy for distributors to remove it if they want or just make it a no-op if we detect all of the dirs setup. Could you mind getting this into a PR?

from rkt.

Sure :)

from rkt.

#588

from rkt.

Somehow this didn't get closed - fixed by #588 and already in 0.4.1

from rkt.