From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753984AbdF0XQl (ORCPT ); Tue, 27 Jun 2017 19:16:41 -0400 Received: from ec2-52-27-115-49.us-west-2.compute.amazonaws.com ([52.27.115.49]:47137 "EHLO osg.samsung.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753880AbdF0XQc (ORCPT ); Tue, 27 Jun 2017 19:16:32 -0400 Subject: Re: selftests/capabilities: test FAIL on linux mainline and linux-next and PASS on linux-4.4.70+ To: Greg KH , Naresh Kamboju , luto@kernel.org Cc: keescook@chromium.org, linux-kselftest@vger.kernel.org, "linux-kernel@vger.kernel.org" , Shuah Khan , Shuah Khan References: <20170627151359.GA11756@kroah.com> <20170627151600.GB11756@kroah.com> From: Shuah Khan Message-ID: Date: Tue, 27 Jun 2017 17:16:24 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170627151600.GB11756@kroah.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/27/2017 09:16 AM, Greg KH wrote: > On Tue, Jun 27, 2017 at 05:13:59PM +0200, Greg KH wrote: >> On Tue, Jun 27, 2017 at 02:10:32PM +0530, Naresh Kamboju wrote: >>> selftest capabilities test failed on linux mainline and linux-next and >>> PASS on linux-4.4.70+ >> >> Odd. Any chance you can use 'git bisect' to track down the offending >> commit? >> >> Does this also fail on x86 or any other platform you have available? >> Let me go try this on my laptop... > > Ok, Linus's current tree (4.12.0-rc7+) also fails on this. I'm guessing > it's failing, it's hard to understand the output. If only we had TAP > output for this test :) As far as the output, it isn't bad. Not TAP13 will help make it better. The problem seems to with the individual messages error/info. messages themselves. This test has the quality of a developer unit test and the messages could be improved for non-developer use. I ran the test on 4.11.8-rc1+ and 4.9.35-rc1 see the same failure. It would be difficult to bisect this since it spans multiple releases. I am hoping Andy can give us some insight. [RUN] +++ Tests with uid == 0 +++ [NOTE] Using global UIDs for tests [RUN] Root => ep [OK] Capabilities after execve were correct [OK] Child succeeded [OK] Check cap_ambient manipulation rules [OK] PR_CAP_AMBIENT_RAISE failed on non-inheritable cap [OK] PR_CAP_AMBIENT_RAISE failed on non-permitted cap [OK] PR_CAP_AMBIENT_RAISE worked [OK] Basic manipulation appears to work [RUN] Root +i => eip [OK] Capabilities after execve were correct [OK] Child succeeded [RUN] UID 0 +ia => eipa [OK] Capabilities after execve were correct [OK] Child succeeded [RUN] Root +ia, suidroot => eipa [OK] Capabilities after execve were correct [OK] Child succeeded [RUN] Root +ia, suidnonroot => ip [FAIL] Wrong effective state (AT_SECURE is not set) [FAIL] Child failed [RUN] Root +ia, sgidroot => eipa [OK] Capabilities after execve were correct [OK] Child succeeded [RUN] Root, gid != 0, +ia, sgidroot => eip [FAIL] Wrong ambient state (AT_SECURE is not set) [FAIL] Child failed [RUN] Root +ia, sgidnonroot => eip [FAIL] Wrong ambient state (AT_SECURE is not set) [FAIL] Child failed [FAIL] Child failed [RUN] +++ Tests with uid != 0 +++ [NOTE] Using global UIDs for tests [RUN] Non-root => no caps [OK] Capabilities after execve were correct [OK] Child succeeded [OK] Check cap_ambient manipulation rules [OK] PR_CAP_AMBIENT_RAISE failed on non-inheritable cap [OK] PR_CAP_AMBIENT_RAISE failed on non-permitted cap [OK] PR_CAP_AMBIENT_RAISE worked [OK] Basic manipulation appears to work [RUN] Non-root +i => i [OK] Capabilities after execve were correct [OK] Child succeeded [RUN] UID 1 +ia => eipa [OK] Capabilities after execve were correct [OK] Child succeeded [RUN] Non-root +ia, sgidnonroot => i [FAIL] Wrong effective state (AT_SECURE is not set) [FAIL] Child failed thanks, -- Shuah