From: Eric Sandeen <sandeen@sandeen.net>
To: Carlos Maiolino <cmaiolino@redhat.com>
Cc: Eric Sandeen <sandeen@redhat.com>, Ben Myers <bpm@sgi.com>,
xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH V2] xfstests: generic/313, test sgid inheritance on subdirs
Date: Thu, 11 Jul 2013 13:34:36 -0500 [thread overview]
Message-ID: <51DEFABC.8020104@sandeen.net> (raw)
In-Reply-To: <20130711182829.GC10711@andromeda.usersys.redhat.com>
On 7/11/13 1:28 PM, Carlos Maiolino wrote:
>>>
>>> generic/313 - output mismatch (see /root/xfstests/results/generic/313.out.bad)
>>> --- tests/generic/313.out 2013-07-08 16:27:41.787710646 -0500
>>> +++ /root/xfstests/results/generic/313.out.bad 2013-07-08 16:47:46.052683735 -0500
>>> @@ -1,3 +1,3 @@
>>> QA output created by 313
>>> -drwxr-sr-x. TEST_DIR/313-dir/subdir
>>> +drwxr-sr-x TEST_DIR/313-dir/subdir
>>> drwxrwsr-x+ TEST_DIR/313-dir/subdir2
>>> ...
>>> (Run 'diff -u tests/generic/313.out /root/xfstests/results/generic/313.out.bad' to see the entire diff)
>>>
>>> Looks like there could be a problem with ls? Have you seen that?
>>>
>>> Thanks,
>>> Ben
>>>
>> Actually I don't think this is a problem, but the way newer `ls` versions are
>> displaying the object permissions (the 'dot' at the end of the permissions,
>> indicating there are no extra attributes).
>>
>> I'm going to take a look on what's going on, but I still believe it's just a
>> matter of add the 'dot' to the xfstests correct output.
>>
>> I had this same problem when testing my patch and needed to fix it locally, but
>> missed to warn you guys, my apologies
>>
> Just a matter of information:
>
> From coreutils:
>
> commit b3677e5e383103bf1764b2c8a9329b1c17934b24
> Author: Jim Meyering <meyering@redhat.com>
> Date: Wed Apr 2 22:26:45 2008 +0200
>
> ls: use '.' (not +) as SELinux-only alt. access flag in ls -l output
>
>
>
> So, this test is selinux dependent, it will provide different outputs whether
> the system has selinux enabled or not.
>
> Since the test itself creates their own directories, checking if the selinux is
> enabled or not and checking the proper output depending on selinux activity
> should avoid false positives on this test. I.e. if the selinux is enabled, the
> `ls -l` output will print the 'dot' at the end of the permissions, otherwise,
> nothing will be printed and Eric's test will pass without problem.
Hm, I thought we always mounted with a global selinux context, and therefore
wouldn't get these differences (i.e. no on-disk selinux attrs should be created)
> I think this is something worth to mention on xfstests README or some other
> documentation, mainly because any kind of test like this, but done with the
> TEST_DEV might be even worst since we don't recreate the filesystem while using
> TEST_DEV, so, objects there can be created with selinux attrs or not (if created
> when selinux is disabled) and have the attributes added later.
It'd be better to just add a filter if we need it.
But I'd like to know why we need it, I thought the global context made these
problems go away...
Guess I'll go look...
-Eric
> I'm probably being too paranoid here talking about the TEST_DEV, but, I thought
> it was worth to mention.
>
> Cheers.
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-07-11 18:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-29 22:30 [PATCH] xfstests: generic/313, test sgid inheritance on subdirs Eric Sandeen
2013-05-30 20:02 ` [PATCH V2] " Eric Sandeen
2013-06-12 19:23 ` Carlos Maiolino
2013-07-08 21:51 ` Ben Myers
2013-07-11 17:53 ` Carlos Maiolino
2013-07-11 18:28 ` Carlos Maiolino
2013-07-11 18:34 ` Eric Sandeen [this message]
2013-07-11 18:53 ` Eric Sandeen
2013-07-12 18:51 ` [PATCH V3] xfstests: generic/314, " Eric Sandeen
2013-07-12 19:21 ` Carlos Maiolino
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51DEFABC.8020104@sandeen.net \
--to=sandeen@sandeen.net \
--cc=bpm@sgi.com \
--cc=cmaiolino@redhat.com \
--cc=sandeen@redhat.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox