Skip to content

Commit

Permalink
change nfs share root mapping, closes #50
Browse files Browse the repository at this point in the history
  • Loading branch information
@nlf
nlf committed Jan 30, 2016
1 parent 4f0b9e6 commit ad08a42
Show file tree
Hide file tree
Showing 2 changed files with 2 additions and 2 deletions.
2 changes: 1 addition & 1 deletion main.go
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ import (
"github.com/jessevdk/go-flags"
)

const VERSION = "1.1.2"
const VERSION = "1.1.3"

type Options struct{}

Expand Down
2 changes: 1 addition & 1 deletion utils/hosts.go
View file
Original file line number Diff line number Diff line change
Expand Up @@ -151,7 +151,7 @@ func AddExport(uuid, share string) error {
share = "/Users"
}

export := fmt.Sprintf("%s -network 192.168.64.0 -mask 255.255.255.0 -alldirs -mapall=%s:%s", share, os.Getenv("SUDO_UID"), os.Getenv("SUDO_GID"))
export := fmt.Sprintf("%s -network 192.168.64.0 -mask 255.255.255.0 -alldirs -maproot=root:wheel", share)
_, err := nfsexports.Add("", "dlite", export)
if err != nil {
return err
Expand Down

3 comments on commit ad08a42

@bpinto
Copy link

@bpinto bpinto commented on ad08a42 Feb 22, 2016

Choose a reason for hiding this comment

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

@nlf This now causes problems as files created from within the VM are not deletable by the user that ran the container. It requires sudo calls.

@jakajancar
Copy link

Choose a reason for hiding this comment

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

I don't think there is a universally good solution here:

  • -mapall=<host_uid>:<host_gid> (e.g. 501:20) has the nice property of files in ~ remaining owned by you (and thus nicely deletable). There is no pollution of the host with ids from another host that do not even correspond to your host's /etc/passwd & /etc/group. The downside is your host user's uid/gid leaks to the container and all the files inside the container will be forced to use it. You cannot chown. Even if you use the popular trick of having your container UID/GID match the host, permission checking will not work OK, since it's done server-side, and there it gets mapped to your host uid (in other words, within the container, "alice" will be able to write to a directory shared from the host, even if that directory seems to be owned by "bob" and has 700). Weird stuff.
  • -maproot=root:wheel will make the container behave more predictably re. permissions, but the host will get polluted by random uids/gids that the system does not even know about.

The ultimate solution would be to keep the files on the host owned by you, but somehow store the guest uids/gids (e.g. in extended attributes) and present those to containers.

Another somewhat-related observation: once you've started dlite, the exports entry does not get reset (even if you purge & reinstall dlite) unless you manually delete /etc/exports, so it's possible that you're using 1.1.3 but still have -mapall there from a previous version (this caused me some confusion just now).

@bpinto
Copy link

@bpinto bpinto commented on ad08a42 Feb 29, 2016

Choose a reason for hiding this comment

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

I have altered my /etc/exports file to use my uid and guid instead. In order to make it work, after doing the changes I ran sudo nfsd update and restarted dlite.

Please sign in to comment.