[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: changing the "+" in ls -l output to be "." or "+"
From: |
Jim Meyering |
Subject: |
Re: RFC: changing the "+" in ls -l output to be "." or "+" |
Date: |
Sun, 26 Oct 2008 09:09:10 +0100 |
Russell Coker <address@hidden> wrote:
> On Saturday 25 October 2008 00:19, Mike Edenfield <address@hidden> wrote:
>> Jim Meyering wrote:
>> > A desire for compatibility makes "+" look good.
>> > "." is appealing for SELinux-only because it's inconspicuous.
>>
>> Speaking as a fairly new SELinux user/admin, having a "."
>> next to every file in my ls output is just as useful or
>> non-useful as having a "+" next to them, so does it really
>> buy anything? I end up needing -Z either way.
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472590
>
> The above URL has the history of this discussion. I requested that there be
> no such notification. I still believe that there should be nothing used in
> the case of SE Linux (although I could be convinced that the "." is OK if
> files with the context "system_u:object_r:file_t:s0" did not have it).
>
> But it seems that I have lost this debate. Using "." is better than "+", and
> my request to have none of this in Lenny has been accepted so we have some
> time to work on this before Lenny+1.
>
>> Based on the kind of real-world problems I've had, the most
>> useful thing ls could tell me about a file on my SELinux
>> system would be that it *should* have a label and *doesn't*,
>> something like:
>>
>> if ( selinux_enabled )
>> if ( label == NULL || label == fs.defaultlabel )
>> use "!"
>> else
>> use " "
>> else if ( anything else )
>> use "+"
>
> That sounds quite reasonable.
Actually, I'm leaning your way, now, and agree.
If you, Russell, write the patch (w/NEWS and docs would be really nice)
I'll make the switch upstream pretty soon. It'd be nice to give the
austin group a heads up, too, since this behavior would be contrary to
POSIX. I don't think it's worth it to make this depend on the setting
of the POSIXLY_CORRECT envvar.