Skip to content

runtimetest: add linux default symbolic link validation - #284

Merged
hqhq merged 1 commit into
opencontainers:masterfrom
Mashimiao:runtime-test-linux-default-symboliclink-validation
Jan 6, 2017
Merged

runtimetest: add linux default symbolic link validation#284
hqhq merged 1 commit into
opencontainers:masterfrom
Mashimiao:runtime-test-linux-default-symboliclink-validation

Conversation

@Mashimiao

Copy link
Copy Markdown

Signed-off-by: Ma Shimiao mashimiao.fnst@cn.fujitsu.com

@Mashimiao

Copy link
Copy Markdown
Author

ping @opencontainers/runtime-tools-maintainers

@liangchenye

liangchenye commented Jan 3, 2017

Copy link
Copy Markdown
Member

LGTM

Approved with PullApprove

@liangchenyeliangchenye mentioned this pull request Jan 3, 2017
76 tasks
Comment threadcmd/runtimetest/main.go Outdated
}

func validateDefaultSymlinks(spec *rspec.Spec) error {
logrus.Debugf("validating linux default Symbolic links")

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

nit: Symbolic -> symbolic

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

fixed, thanks

Signed-off-by: Ma Shimiao <mashimiao.fnst@cn.fujitsu.com>
@Mashimiao
Mashimiaoforce-pushed the runtime-test-linux-default-symboliclink-validation branch from 22706e1 to da25004CompareJanuary 5, 2017 01:10
@Mashimiao

Copy link
Copy Markdown
Author

@mrunalp@liangchenye PTAL

@mrunalp

mrunalp commented Jan 5, 2017

Copy link
Copy Markdown
Contributor

LGTM

Approved with PullApprove

1 similar comment
@hqhq

hqhq commented Jan 6, 2017

Copy link
Copy Markdown
Contributor

LGTM

Approved with PullApprove

@hqhq
hqhq merged commit 1bfd892 into opencontainers:masterJan 6, 2017
@liangchenyeliangchenye mentioned this pull request Jun 29, 2017
58 tasks
wking added a commit to wking/ocitools-v2 that referenced this pull request Apr 6, 2018
We've been using ModeSymlink as the mask since the check landed in
da25004 (runtimetest: add linux default symbolic link validation,
2016-11-30, opencontainers#284). POSIX provides S_IS*(m) macros to portably
interpret the mode type, but does not define values for each type [2].
Alban pointed out that st_mode is not a bitfield on Linux [1]. For
example, Linux defines [3]:
S_IFBLK 060000
S_IFDIR 040000
S_IFCHR 020000
So 'm&S_IFCHR == S_IFCHR', for example, would succeed for both
character and block devices. Go translates the system values to a
platform-agnostic bitfield [4], so the previous approach works on Go.
But it may be confusing for people used to the native non-bitfield
mode, so this commit moves us to an approach that does not rely on
Go's using a bitfield.
[1]: opencontainers#308 (comment)
[2]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html
[3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/stat.h?h=v4.16#n9
[4]: https://github.com/golang/go/blob/b0d437f866eb8987cde7e6550cacd77876f36d4b/src/os/types.go#L45
Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/ocitools-v2 that referenced this pull request Apr 6, 2018
We've been using ModeSymlink as the mask since the check landed in
da25004 (runtimetest: add linux default symbolic link validation,
2016-11-30, opencontainers#284). POSIX provides S_IS*(m) macros to portably
interpret the mode type, but does not define values for each type [2].
Alban pointed out that st_mode is not a bitfield on Linux [1]. For
example, Linux defines [3]:
S_IFBLK 060000
S_IFDIR 040000
S_IFCHR 020000
So 'm&S_IFCHR == S_IFCHR', for example, would succeed for both
character and block devices. Go translates the system values to a
platform-agnostic bitfield [4], so the previous approach works on Go.
But it may be confusing for people used to the native non-bitfield
mode, so this commit moves us to an approach that does not rely on
Go's using a bitfield.
[1]: opencontainers#308 (comment)
[2]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html
[3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/stat.h?h=v4.16#n9
[4]: https://github.com/golang/go/blob/b0d437f866eb8987cde7e6550cacd77876f36d4b/src/os/types.go#L45
Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/ocitools-v2 that referenced this pull request Apr 6, 2018
We've been using ModeSymlink as the mask since the check landed in
da25004 (runtimetest: add linux default symbolic link validation,
2016-11-30, opencontainers#284). POSIX provides S_IS*(m) macros to portably
interpret the mode type, but does not define values for each type [2].
Alban pointed out that st_mode is not a bitfield on Linux [1]. For
example, Linux defines [3]:
S_IFBLK 060000
S_IFDIR 040000
S_IFCHR 020000
So 'm&S_IFCHR == S_IFCHR', for example, would succeed for both
character and block devices. Go translates the system values to a
platform-agnostic bitfield [4], so the previous approach works on Go.
But it may be confusing for people used to the native non-bitfield
mode, so this commit moves us to an approach that does not rely on
Go's using a bitfield.
[1]: opencontainers#308 (comment)
[2]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html
[3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/stat.h?h=v4.16#n9
[4]: https://github.com/golang/go/blob/b0d437f866eb8987cde7e6550cacd77876f36d4b/src/os/types.go#L45
Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/ocitools-v2 that referenced this pull request Apr 6, 2018
We've been using ModeSymlink as the mask since the check landed in
da25004 (runtimetest: add linux default symbolic link validation,
2016-11-30, opencontainers#284). POSIX provides S_IS*(m) macros to portably
interpret the mode type, but does not define values for each type [2].
Alban pointed out that st_mode is not a bitfield on Linux [1]. For
example, Linux defines [3]:
S_IFBLK 060000
S_IFDIR 040000
S_IFCHR 020000
So 'm&S_IFCHR == S_IFCHR', for example, would succeed for both
character and block devices. Go translates the system values to a
platform-agnostic bitfield [4], so the previous approach works on Go.
But it may be confusing for people used to the native non-bitfield
mode, so this commit moves us to an approach that does not rely on
Go's using a bitfield.
[1]: opencontainers#308 (comment)
[2]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html
[3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/stat.h?h=v4.16#n9
[4]: https://github.com/golang/go/blob/b0d437f866eb8987cde7e6550cacd77876f36d4b/src/os/types.go#L45
Signed-off-by: W. Trevor King <wking@tremily.us>
wking added a commit to wking/ocitools-v2 that referenced this pull request Apr 6, 2018
We've been using ModeSymlink as the mask since the check landed in
da25004 (runtimetest: add linux default symbolic link validation,
2016-11-30, opencontainers#284). POSIX provides S_IS*(m) macros to portably
interpret the mode type, but does not define values for each type [2].
Alban pointed out that st_mode is not a bitfield on Linux [1]. For
example, Linux defines [3]:
S_IFBLK 060000
S_IFDIR 040000
S_IFCHR 020000
So 'm&S_IFCHR == S_IFCHR', for example, would succeed for both
character and block devices. Go translates the system values to a
platform-agnostic bitfield [4], so the previous approach works on Go.
But it may be confusing for people used to the native non-bitfield
mode, so this commit moves us to an approach that does not rely on
Go's using a bitfield.
[1]: opencontainers#308 (comment)
[2]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html
[3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/stat.h?h=v4.16#n9
[4]: https://github.com/golang/go/blob/b0d437f866eb8987cde7e6550cacd77876f36d4b/src/os/types.go#L45
Signed-off-by: W. Trevor King <wking@tremily.us>
Sign up for freeto 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.

4 participants

@Mashimiao@liangchenye@mrunalp@hqhq