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

set unix.MS_BIND flag for bind mount #1799

Closed
wants to merge 1 commit into from

Conversation

binchenX
Copy link
Contributor

@binchenX binchenX commented May 8, 2018

always set unix.MS_BIND flag for bind mount, this fixs a error reporting
"no such device" with following mount configration, which is similar to
mount --bind oldidr newdir

{
"destination": "/host_dir",
"type": "bind",
"source": "host_dir"
}

Without this change, we always have to set the "options":
["rbind"], which will add the flag unix.MS_BIND in parseMountOptions.

Alternative fix is to add option "bind" to Mount.Options when it is bind
mount so the right flag can be set in parseMountOptions.

Signed-off-by: Bin Chen nk@devicu.com

always set unix.MS_BIND flag for bind mount, this fixs a error reporting
"no such device" with following  mount configration, which is similar to
mount --bind oldidr newdir

{
     "destination": "/host_dir",
     "type": "bind",
     "source": "host_dir"
}

Without this change, we always have to set the "options":
["rbind"], which will add the flag unix.MS_BIND in parseMountOptions.

Alternative fix is to add option "bind" to Mount.Options when it is bind
mount so the right flag can be set in parseMountOptions.

Signed-off-by: Bin Chen <nk@devicu.com>
@cyphar
Copy link
Member

cyphar commented May 8, 2018

Rejected -- type: "bind" is not a valid way of specifying bind-mounts in the OCI specification. Unfortunately quite a few people have used it historically, leading to confusion (and the code itself used to depend on it as well -- which is a mess as well).

Rejected with PullApprove

@binchenX
Copy link
Contributor Author

binchenX commented May 8, 2018 via email

@binchenX
Copy link
Contributor Author

binchenX commented May 8, 2018

Here is the example used in the runtime-spec.
https://github.com/opencontainers/runtime-spec/blob/master/config.md#example-linux

"mounts": [
    {
        "destination": "/data",
        "type": "bind",
        "source": "/volumes/testing",
        "options": ["rbind","rw"]
    }
]

Without the fix, you have to specify the "options": ["rbind","rw"], otherwise, it will throw error "no device found".

binchenX pushed a commit to binchenX/runtime-spec that referenced this pull request May 9, 2018
Per spec, "bind" is not a valid mount type. To use bind mount,
the spec compatible way is to set either "bind" or "rbind"
in the mount options.

Although in practice, setting the type as "bind" won't actually
cause an error (at the moment using runc, as well as the system
call mount(7) itself) as long as either "bind" or "rbind" is set
as well, it provide an incorrect example that "bind" is avalid
type, and make people think following config is a valid one for
bind mount, which in fact will throw an error in runc.

{
 "destination": "/data",
 "type": "bind"
 "source": "/volumes/testing",
}

[1] tried to automatically add a MS_BIND flag when the type is "bind"
but was rejected on the ground it "encourage" the incorrect usage of
bind as the mount type, which I agree. Hence, here I change the example
in the spec in the hope making it clearer that for bind mount to work,
we should use the correct mount options, instead of the "bind" mount type.

[1]opencontainers/runc#1799

Signed-off-by: Bin Chen <Bin Chen nk@devicu.com>

Signed-off-by: Bin Chen <Bin Chen nk@devicu.com>
binchenX pushed a commit to binchenX/runtime-spec that referenced this pull request May 9, 2018
Per spec, "bind" is not a valid mount type. To use bind mount,
the spec compatible way is to set either "bind" or "rbind"
in the mount options.

Although in practice, setting the type as "bind" won't actually
cause an error (at the moment using runc, as well as the system
call mount(7) itself) as long as either "bind" or "rbind" is set
as well, it provide an incorrect example that "bind" is avalid
type, and make people think following config is a valid one for
bind mount, which in fact will throw an error in runc.

{
 "destination": "/data",
 "type": "bind"
 "source": "/volumes/testing",
}

[1] tried to automatically add a MS_BIND flag when the type is "bind"
but was rejected on the ground it "encourage" the incorrect usage of
bind as the mount type, which I agree. Hence, here I change the example
in the spec in the hope making it clearer that for bind mount to work,
we should use the correct mount options, instead of the "bind" mount type.

[1]opencontainers/runc#1799

Signed-off-by: Bin Chen <Bin Chen nk@devicu.com>
binchenX pushed a commit to binchenX/runtime-spec that referenced this pull request May 9, 2018
Per spec, "bind" is not a valid mount type. To use bind mount,
the spec compatible way is to set either "bind" or "rbind"
in the mount options.

Although in practice, setting the type as "bind" won't actually
cause an error (at the moment using runc, as well as the system
call mount(7) itself) as long as either "bind" or "rbind" is set
as well, it provide an incorrect example that "bind" is avalid
type, and make people think following config is a valid one for
bind mount, which in fact will throw an error in runc.

{
 "destination": "/data",
 "type": "bind"
 "source": "/volumes/testing",
}

[1] tried to automatically add a MS_BIND flag when the type is "bind"
but was rejected on the ground it "encourage" the incorrect usage of
bind as the mount type, which I agree. Hence, here I change the example
in the spec in the hope making it clearer that for bind mount to work,
we should use the correct mount options, instead of the "bind" mount type.

[1]opencontainers/runc#1799

Signed-off-by: Bin Chen <nk@devicu.com>
binchenX added a commit to binchenX/runtime-spec that referenced this pull request May 9, 2018
Per spec, "bind" is not a valid mount type. To use bind mount,
the spec compatible way is to set either "bind" or "rbind"
in the mount options.

Although in practice, setting the type as "bind" won't actually
cause an error (at the moment using runc, as well as the system
call mount(7) itself) as long as either "bind" or "rbind" is set
as well, it provide an incorrect example that "bind" is avalid
type, and make people think following config is a valid one for
bind mount, which in fact will throw an error in runc.

{
 "destination": "/data",
 "type": "bind"
 "source": "/volumes/testing",
}

[1] tried to automatically add a MS_BIND flag when the type is "bind"
but was rejected on the ground it "encourage" the incorrect usage of
bind as the mount type, which I agree. Hence, here I change the example
in the spec in the hope making it clearer that for bind mount to work,
we should use the correct mount options, instead of the "bind" mount type.

[1]opencontainers/runc#1799

Signed-off-by: Bin Chen <nk@devicu.com>
binchenX added a commit to binchenX/runtime-spec that referenced this pull request May 9, 2018
Per spec, "bind" is not a valid mount type. To use bind mount,
the spec compatible way is to set either "bind" or "rbind"
in the mount options.

Although in practice, setting the type as "bind" won't actually
cause an error (at the moment using runc, as well as the system
call mount(7) itself) as long as either "bind" or "rbind" is set
as well, it provide an incorrect example that "bind" is avalid
type, and make people think following config is a valid one for
bind mount, which in fact will throw an error in runc.

{
 "destination": "/data",
 "type": "bind"
 "source": "/volumes/testing",
}

[1] tried to automatically add a MS_BIND flag when the type is "bind"
but was rejected on the ground it "encourage" the incorrect usage of
bind as the mount type, which I agree. Hence, here I change the example
in the spec in the hope making it clearer that for bind mount to work,
we should use the correct mount options, instead of the "bind" mount type.

[1]opencontainers/runc#1799

Signed-off-by: Bin Chen <nk@devicu.com>
@AkihiroSuda
Copy link
Member

@AkihiroSuda AkihiroSuda closed this Mar 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants