[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8760fww7bs.fsf@concordia.ellerman.id.au>
Date: Fri, 16 Jun 2017 20:33:11 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: NeilBrown <neilb@...e.com>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: Ian Kent <raven@...maw.net>, LKML <linux-kernel@...r.kernel.org>,
autofs mailing list <autofs@...r.kernel.org>
Subject: Re: [PATCH] autofs: sanity check status reported with AUTOFS_DEV_IOCTL_FAIL
NeilBrown <neilb@...e.com> writes:
> On Thu, Jun 15 2017, Andrew Morton wrote:
>> On Wed, 07 Jun 2017 12:08:38 +1000 NeilBrown <neilb@...e.com> wrote:
>>> --- a/fs/autofs4/dev-ioctl.c
>>> +++ b/fs/autofs4/dev-ioctl.c
>>> @@ -344,7 +344,7 @@ static int autofs_dev_ioctl_fail(struct file *fp,
>>> int status;
>>>
>>> token = (autofs_wqt_t) param->fail.token;
>>> - status = param->fail.status ? param->fail.status : -ENOENT;
>>> + status = param->fail.status < 0 ? param->fail.status : -ENOENT;
>>> return autofs4_wait_release(sbi, token, status);
>>> }
>>
>> Sounds serious. Was the absence of a cc:stable deliberate?
>
> You need CAP_SYS_ADMIN to get the ioctl even looked at. Doesn't that
> mean the bug can only be triggered by a process that could easily do
> worse?
>
> Or do containers allow admins to give out CAP_SYS_ADMIN to untrusted
> people?? I haven't been keeping up.
Yep. They can be configured individually in fact, eg:
$ docker run --cap-drop=ALL --cap-add=sys_admin -it debian:jessie /bin/bash
root@...ebe8c46e0:/# capsh --print
Current: = cap_sys_admin+eip
Bounding set =cap_sys_admin
Securebits: 00/0x0/1'b0
secure-noroot: no (unlocked)
secure-no-suid-fixup: no (unlocked)
secure-keep-caps: no (unlocked)
uid=0(root)
gid=0(root)
groups=
cheers
Powered by blists - more mailing lists