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.

Sign up for GitHub

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

IDMapping field for mount point #1143

Merged
merged 1 commit into from
Jun 1, 2022
+22 −0
Merged

IDMapping field for mount point #1143

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions config.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -101,6 +101,11 @@ For POSIX platforms the `mounts` structure has the following fields:
* **`type`** (string, OPTIONAL) The type of the filesystem to be mounted.
* Linux: filesystem types supported by the kernel as listed in */proc/filesystems* (e.g., "minix", "ext2", "ext3", "jfs", "xfs", "reiserfs", "msdos", "proc", "nfs", "iso9660"). For bind mounts (when `options` include either `bind` or `rbind`), the type is a dummy, often "none" (not listed in */proc/filesystems*).
* Solaris: corresponds to "type" of the fs resource in [zonecfg(1M)][zonecfg.1m].
* **`uidMappings`** (array of type LinuxIDMapping, OPTIONAL) The mapping to convert UIDs from the source file system to the destination mount point.\
The format is the same as [user namespace mappings](config-linux.md#user-namespace-mappings).
* **`gidMappings`** (array of type LinuxIDMapping, OPTIONAL) The mapping to convert GIDs from the source file system to the destination mount point.
For more details see `uidMappings`.

Copy link
Member

Choose a reason for hiding this comment

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

Is there any specific reason that we don't have this for rootfs?

Copy link
Member

Choose a reason for hiding this comment

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

we don't have other mount options for rootfs.

And practically, it won't be very helpful since overlay doesn't support idmapped mounts on the overlay mount itself (only on the lower layers).

Copy link
Member

Choose a reason for hiding this comment

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

Also, the spec currently says the runtime should not modify the rootfs permissions: https://github.com/opencontainers/runtime-spec/blob/main/config-linux.md#user-namespace-mappings

The runtime SHOULD NOT modify the ownership of referenced filesystems to realize the mapping.


### Example (Linux)

Expand Down
12 changes: 12 additions & 0 deletions schema/defs.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -141,6 +141,18 @@
},
"type": {
"type": "string"
},
"uidMappings": {
"type": "array",
"items": {
"$ref": "#/definitions/IDMapping"
}
},
"gidMappings": {
"type": "array",
"items": {
"$ref": "#/definitions/IDMapping"
}
}
},
"required": [
Expand Down
5 changes: 5 additions & 0 deletions specs-go/config.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -117,6 +117,11 @@ type Mount struct {
Source string `json:"source,omitempty"`
// Options are fstab style mount options.
Options []string `json:"options,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

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

The idmap option is one of the fstab options and that is why we don't need to mention it in any other part of the spec?

Copy link
Member

Choose a reason for hiding this comment

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

I guess it is explicit when a mapping is specified?

Copy link
Member

Choose a reason for hiding this comment

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

Oh, so we use idmap if a mapping is specified? Makes sense. Thanks!


// UID/GID mappings used for changing file owners w/o calling chown, fs should support it.
// Every mount point could have its own mapping.
UIDMappings []LinuxIDMapping `json:"uidMappings,omitempty" platform:"linux"`
GIDMappings []LinuxIDMapping `json:"gidMappings,omitempty" platform:"linux"`
}

// Hook specifies a command that is run at a particular event in the lifecycle of a container
Expand Down