Message ID | 552FA066.3010905@huawei.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Thu, Apr 16, 2015 at 07:43:34PM +0800, Wuqixuan wrote: > The process, supposed in one container, can't flush the metadata > and data of the all host's partitions without CAP_SYS_ADMIN > capability, like sys_mount is doing. The checking will prevent some > vicious programs impacting IO sequnces of those partitions, > particularly, the ones which can't be accessed in the container. > > Signed-off-by: Last Wu <wuqixuan@huawei.com> > --- > fs/sync.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fs/sync.c b/fs/sync.c > index fbc98ee..9f07909 100644 > --- a/fs/sync.c > +++ b/fs/sync.c > @@ -103,6 +103,9 @@ SYSCALL_DEFINE0(sync) > { > int nowait = 0, wait = 1; > > + if (!capable(CAP_SYS_ADMIN)) > + return -EPERM; So after this patch I can't call sync as a regular user? (even without containers). But nothing in sync(2) says about special permissions for this. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 16, 2015 at 5:08 PM, Azat Khuzhin <a3at.mail@gmail.com> wrote: > On Thu, Apr 16, 2015 at 07:43:34PM +0800, Wuqixuan wrote: >> The process, supposed in one container, can't flush the metadata >> and data of the all host's partitions without CAP_SYS_ADMIN >> capability, like sys_mount is doing. The checking will prevent some >> vicious programs impacting IO sequnces of those partitions, >> particularly, the ones which can't be accessed in the container. >> >> Signed-off-by: Last Wu <wuqixuan@huawei.com> >> --- >> fs/sync.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/fs/sync.c b/fs/sync.c >> index fbc98ee..9f07909 100644 >> --- a/fs/sync.c >> +++ b/fs/sync.c >> @@ -103,6 +103,9 @@ SYSCALL_DEFINE0(sync) >> { >> int nowait = 0, wait = 1; >> >> + if (!capable(CAP_SYS_ADMIN)) >> + return -EPERM; > > So after this patch I can't call sync as a regular user? (even without > containers). > But nothing in sync(2) says about special permissions for this. Yeah, this solution will break userspace. A much more generic solution would be to wait for cgroup aware writeback[1]. As temporary hack you can check whether the calling process is in the initial pid namesapce to detect a container calling sync(2)... [1] https://lwn.net/Articles/628631/
Thanks for your both replies. We will waiting for the patchset, and modify as per Richard's suggestion for temporary hack. On 2015/4/17 3:31, Richard Weinberger wrote: > On Thu, Apr 16, 2015 at 5:08 PM, Azat Khuzhin <a3at.mail@gmail.com> wrote: >> On Thu, Apr 16, 2015 at 07:43:34PM +0800, Wuqixuan wrote: >>> The process, supposed in one container, can't flush the metadata >>> and data of the all host's partitions without CAP_SYS_ADMIN >>> capability, like sys_mount is doing. The checking will prevent some >>> vicious programs impacting IO sequnces of those partitions, >>> particularly, the ones which can't be accessed in the container. >>> >>> Signed-off-by: Last Wu <wuqixuan@huawei.com> >>> --- >>> fs/sync.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/fs/sync.c b/fs/sync.c >>> index fbc98ee..9f07909 100644 >>> --- a/fs/sync.c >>> +++ b/fs/sync.c >>> @@ -103,6 +103,9 @@ SYSCALL_DEFINE0(sync) >>> { >>> int nowait = 0, wait = 1; >>> >>> + if (!capable(CAP_SYS_ADMIN)) >>> + return -EPERM; >> So after this patch I can't call sync as a regular user? (even without >> containers). >> But nothing in sync(2) says about special permissions for this. > Yeah, this solution will break userspace. > A much more generic solution would be to wait for cgroup aware writeback[1]. > As temporary hack you can check whether the calling process is in the > initial pid namesapce to detect > a container calling sync(2)... > > [1] https://lwn.net/Articles/628631/ > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/sync.c b/fs/sync.c index fbc98ee..9f07909 100644 --- a/fs/sync.c +++ b/fs/sync.c @@ -103,6 +103,9 @@ SYSCALL_DEFINE0(sync) { int nowait = 0, wait = 1; + if (!capable(CAP_SYS_ADMIN)) + return -EPERM; + wakeup_flusher_threads(0, WB_REASON_SYNC); iterate_supers(sync_inodes_one_sb, NULL); iterate_supers(sync_fs_one_sb, &nowait);
The process, supposed in one container, can't flush the metadata and data of the all host's partitions without CAP_SYS_ADMIN capability, like sys_mount is doing. The checking will prevent some vicious programs impacting IO sequnces of those partitions, particularly, the ones which can't be accessed in the container. Signed-off-by: Last Wu <wuqixuan@huawei.com> --- fs/sync.c | 3 +++ 1 file changed, 3 insertions(+) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html