Open borqosky opened 8 years ago
@jellonek @ppalucki @mpatelcz @mstachowski : seems to prepare-app.c
is ok for hacking it ?
Line 156
static const mount_point files_mount_table[] = {
{ "/etc/rkt-resolv.conf", "/etc/resolv.conf", "bind", NULL, MS_BIND },
};
What do you think ?
Wrong description - this is not connected with 9p.
is it problem only when specifying volumes by manifests ? (can I reproduce the same simply with -v host:/x/somefile.txt
?
as proposed by @jellonek we can mitigate that just mounting single directory and bind mounting required subfolder and files - but we end up we security issues realated to protecting the host filesystem
ps. please move that as an issue to coreos/rkt, its better to continue this discussion there
@jellonek I don't understand - it exactly problem of 9p - that it cannot share a single file
by 9p volume is treated as directory (not device and not file) that is all
@ppalucki: As far as I know, there is no filesystem which provide functionality of mounting single as a volume. In 'coreos' flavor, you are able to bind-mount single file into stage{1,2} rootfs. This way it isn't 9p problem, but overuse of bind-mount in 'coreos' flavor.
Not exactly "overuse". but you are close to that what i had in mind writing this comment. It's more like "method which we used as volume provider - can not provide this functionality" as any other method than bind-mounting on host - can provide this in easy way (other possibility is to provide whole directory - or even whole rootfs of host - to container and then/there bindmount it as it's done by prepare app).
Steps to reproduce:
sudo ./rkt prepare --pod-manifest nginx_default.json --stage1-path stage1-kvm.aci
nginx_default.json
sudo ./rkt run-prepared $UUID
Got error: