Re: RFC: changing the + in ls -l output to be . or +

2009-04-07 Thread Pádraig Brady
Jim Meyering wrote:
 Pádraig Brady wrote:
 ...
 I'll also look at documenting the ls SElinux options in the info docs
 as I couldn't see them on a quick search.
 
 Nice.  That will we welcome.
 If you feel really industrious, mktemp needs info documentation, too.

Ah the SELinux stuff was a TODO, and not just for `ls`.
Hopefully I caught them all in the attached.

cheers,
Pádraig.

p.s. I noticed some inconsistencies with how contexts were handled.
For example `mkdir`, `mkfifo`, `mknod` don't check is_selinux_enabled()
whereas `install` does. Probably OK, but worth noting I think.

From 39b4994561ccec9ba1cd9e10cb33b6b308dbcf6b Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
Date: Mon, 6 Apr 2009 19:21:51 +0100
Subject: [PATCH] doc: add missing documentation for some SELinux options

* doc/coreutils.texi (ls invocation): Describe the --context (-Z) option
(install invocation): Describe the --preserve-context and -Z options
(id invocation): Describe the --context (-Z) option
(mkdir invocation): Describe the --context (-Z) option
(mknod invocation): Describe the --context (-Z) option
(mkfifo invocation): Describe the --context (-Z) option
* TODO: remove the todo item
---
 TODO   |1 -
 doc/coreutils.texi |   64 
 2 files changed, 64 insertions(+), 1 deletions(-)

diff --git a/TODO b/TODO
index 7288285..9128ddf 100644
--- a/TODO
+++ b/TODO
@@ -15,7 +15,6 @@ document the following in coreutils.texi:
   mktemp
   [
   pinky
-Also document the SELinux changes.
 
 Suggestion from Paul Eggert:
   More generally, there's not that much use for imaxtostr nowadays,
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 70effa1..5bc4706 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -6540,6 +6540,16 @@ it also affects the HP-UX @command{ls} program.
 
 @optSi
 
+...@item -Z
+...@itemx --context
+...@opindex -Z
+...@opindex --context
+...@cindex SELinux
+...@cindex security context
+Display the SELinux security context or @samp{?} if none is found. When used
+with the @option{-l} option, the security context is printed to the left
+of the size column.
+
 @end table
 
 
@@ -8045,6 +8055,15 @@ ownership of installed files or directories to @var{owner}.  The default
 is @code{root}.  @var{owner} may be either a user name or a numeric user
 ID.
 
+...@itemx --preserve-context
+...@opindex --preserve-context
+...@cindex SElinux
+...@cindex security context
+Preserve the SELinux security context of files and directories.
+Failure to preserve the context in all of the files or directories
+will result in an exit status of 1. If SELinux is disabled then
+a warning is printed and the option is ignored.
+
 @item -p
 @itemx --preserve-timestamps
 @opindex -p
@@ -8083,6 +8102,16 @@ Program used to strip binaries.
 @opindex --verbose
 Print the name of each file before copying it.
 
+...@item -Z @var{context}
+...@itemx --conte...@var{context}
+...@opindex -Z
+...@opindex --context
+...@cindex SELinux
+...@cindex security context
+Set the default SELinux security context to be used for any
+created files and directories. If SELinux is disabled then
+a warning is printed and the option is ignored.
+
 @end table
 
 @exitstatus
@@ -8917,6 +8946,15 @@ newly-created parent directories are inherited.
 @opindex --verbose
 Print a message for each created directory.  This is most useful with
 @option{--parents}.
+
+...@item -Z @var{context}
+...@itemx --conte...@var{context}
+...@opindex -Z
+...@opindex --context
+...@cindex SELinux
+...@cindex security context
+Set the default SELinux security context to be used for created directories.
+
 @end table
 
 @exitstatus
@@ -8956,6 +8994,14 @@ Set the mode of created FIFOs to @var{mode}, which is symbolic as in
 for the point of departure.  @var{mode} should specify only file
 permission bits.  @xref{File permissions}.
 
+...@item -Z @var{context}
+...@itemx --conte...@var{context}
+...@opindex -Z
+...@opindex --context
+...@cindex SELinux
+...@cindex security context
+Set the default SELinux security context to be used for created FIFOs.
+
 @end table
 
 @exitstatus
@@ -9031,6 +9077,14 @@ Set the mode of created files to @var{mode}, which is symbolic as in
 @var{mode} should specify only file permission bits.
 @xref{File permissions}.
 
+...@item -Z @var{context}
+...@itemx --conte...@var{context}
+...@opindex -Z
+...@opindex --context
+...@cindex SELinux
+...@cindex security context
+Set the default SELinux security context to be used for created files.
+
 @end table
 
 @exitstatus
@@ -12737,6 +12791,16 @@ Print the real, instead of effective, user or group ID.  Requires
 @opindex --user
 Print only the user ID.
 
+...@item -Z
+...@itemx --context
+...@opindex -Z
+...@opindex --context
+...@cindex SELinux
+...@cindex security context
+Print only the security context of the current user.
+If SELinux is disabled then a warning is printed and
+the exit status is 1.
+
 @end table

Re: RFC: changing the + in ls -l output to be . or +

2009-04-07 Thread Pádraig Brady
Pádraig Brady wrote:
 Jim Meyering wrote:
 You might want to do something similar to what I did in fts.c
 with this change:

 http://git.sv.gnu.org/cgit/gnulib.git/commit/?id=97d5b66578be507
 
 Oh cool, thanks for that.

Hmm, looks like my Fedora 8 system at least with SELinux disabled,
will print security context for some files only.
I.E. I'm not sure it's possible to cache for performance.

cheers,
Pádraig.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: RFC: changing the + in ls -l output to be . or +

2009-04-07 Thread Andreas Schwab
Pádraig Brady p...@draigbrady.com writes:

 @@ -8045,6 +8055,15 @@ ownership of installed files or directories to 
 @var{owner}.  The default
  is @code{root}.  @var{owner} may be either a user name or a numeric user
  ID.
  
 +...@itemx --preserve-context

s/@itemx/@item/

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: RFC: changing the + in ls -l output to be . or +

2009-04-07 Thread Jim Meyering
Pádraig Brady wrote:
 Jim Meyering wrote:
 Pádraig Brady wrote:
 ...
 I'll also look at documenting the ls SElinux options in the info docs
 as I couldn't see them on a quick search.

 Nice.  That will we welcome.
 If you feel really industrious, mktemp needs info documentation, too.

 Ah the SELinux stuff was a TODO, and not just for `ls`.
 Hopefully I caught them all in the attached.

 cheers,
 Pádraig.

 p.s. I noticed some inconsistencies with how contexts were handled.
 For example `mkdir`, `mkfifo`, `mknod` don't check is_selinux_enabled()
 whereas `install` does. Probably OK, but worth noting I think.

I think it's fine.

When the mk* commands try to perform selinux-related syscalls, they'll
fail due an error return from one of the stub replacement functions.
The test in install is so that -Z and --preserve-context can be used
without penalty on non-SELinux-enabled systems.  I didn't want to do
that for the mk* programs.

quick comments on doc changes:
First, thanks a lot.
This is long overdue.

From 39b4994561ccec9ba1cd9e10cb33b6b308dbcf6b Mon Sep 17 00:00:00 2001
 From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
 Date: Mon, 6 Apr 2009 19:21:51 +0100
 Subject: [PATCH] doc: add missing documentation for some SELinux options

 * doc/coreutils.texi (ls invocation): Describe the --context (-Z) option
 (install invocation): Describe the --preserve-context and -Z options
 (id invocation): Describe the --context (-Z) option
 (mkdir invocation): Describe the --context (-Z) option
 (mknod invocation): Describe the --context (-Z) option
 (mkfifo invocation): Describe the --context (-Z) option
 * TODO: remove the todo item
 ---
  TODO   |1 -
  doc/coreutils.texi |   64 
 
  2 files changed, 64 insertions(+), 1 deletions(-)

 diff --git a/TODO b/TODO
 index 7288285..9128ddf 100644
 --- a/TODO
 +++ b/TODO
 @@ -15,7 +15,6 @@ document the following in coreutils.texi:
mktemp
[
pinky
 -Also document the SELinux changes.

  Suggestion from Paul Eggert:
More generally, there's not that much use for imaxtostr nowadays,
 diff --git a/doc/coreutils.texi b/doc/coreutils.texi
 index 70effa1..5bc4706 100644
 --- a/doc/coreutils.texi
 +++ b/doc/coreutils.texi
 @@ -6540,6 +6540,16 @@ it also affects the HP-UX @command{ls} program.

  @optSi

 +...@item -Z
 +...@itemx --context
 +...@opindex -Z
 +...@opindex --context
 +...@cindex SELinux
 +...@cindex security context
 +Display the SELinux security context or @samp{?} if none is found. When used
 +with the @option{-l} option, the security context is printed to the left
 +of the size column.

Please don't write ... is printed
That's using what's called the passive voice.
Use an active voice instead, i.e., change the last sentence to this:

When used with the @option{-l} option, print the security context
to the left of the size column.

Please do the same for the three others below.

  @end table
...


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: RFC: changing the + in ls -l output to be . or +

2009-04-07 Thread Pádraig Brady
Jim Meyering wrote:
 Pádraig Brady wrote:
 Pádraig Brady wrote:
 Jim Meyering wrote:
 You might want to do something similar to what I did in fts.c
 with this change:

 http://git.sv.gnu.org/cgit/gnulib.git/commit/?id=97d5b66578be507
 Oh cool, thanks for that.
 Hmm, looks like my Fedora 8 system at least with SELinux disabled,
 will print security context for some files only.
 I.E. I'm not sure it's possible to cache for performance.
 
 Please clarify.  What commands are you using?
 Two files on the same partition?
 One has SELinux context and the other doesn't?

yep

$ head -n1 /etc/issue
Fedora release 8 (Werewolf)
$ selinuxenabled || echo disabled
disabled
$ ./ls -1Zd ~/public_html ~/ttt
user_u:object_r:httpd_sys_content_t:s0 ~/public_html
 ? ~/ttt

cheers,
Pádraig.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: RFC: changing the + in ls -l output to be . or +

2009-04-07 Thread Jim Meyering
Pádraig Brady wrote:
 Pádraig Brady wrote:
 Jim Meyering wrote:
 You might want to do something similar to what I did in fts.c
 with this change:

 http://git.sv.gnu.org/cgit/gnulib.git/commit/?id=97d5b66578be507

 Oh cool, thanks for that.

 Hmm, looks like my Fedora 8 system at least with SELinux disabled,
 will print security context for some files only.
 I.E. I'm not sure it's possible to cache for performance.

Please clarify.  What commands are you using?
Two files on the same partition?
One has SELinux context and the other doesn't?


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: RFC: changing the + in ls -l output to be . or +

2009-04-07 Thread Jim Meyering
Pádraig Brady wrote:

 Jim Meyering wrote:
 Pádraig Brady wrote:
 Pádraig Brady wrote:
 Jim Meyering wrote:
 You might want to do something similar to what I did in fts.c
 with this change:

 http://git.sv.gnu.org/cgit/gnulib.git/commit/?id=97d5b66578be507
 Oh cool, thanks for that.
 Hmm, looks like my Fedora 8 system at least with SELinux disabled,
 will print security context for some files only.
 I.E. I'm not sure it's possible to cache for performance.

 Please clarify.  What commands are you using?
 Two files on the same partition?
 One has SELinux context and the other doesn't?

 yep

 $ head -n1 /etc/issue
 Fedora release 8 (Werewolf)
 $ selinuxenabled || echo disabled
 disabled
 $ ./ls -1Zd ~/public_html ~/ttt
 user_u:object_r:httpd_sys_content_t:s0 ~/public_html

Glad you noticed that.
I chatted with Eric Paris on IRC and he explained
(as I should have known) that you could very well have a
device with some files having SELinux context and others
having none.  That would not be very likely in practice,
(esp. for fixed drives) but for removable, it's more plausible.

So caching that attribute would not work after all.
Oh well.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: RFC: changing the + in ls -l output to be . or +

2009-04-07 Thread Pádraig Brady
Andreas Schwab wrote:
 Pádraig Brady p...@draigbrady.com writes:
 
 @@ -8045,6 +8055,15 @@ ownership of installed files or directories to 
 @var{owner}.  The default
  is @code{root}.  @var{owner} may be either a user name or a numeric user
  ID.
  
 +...@itemx --preserve-context
 
 s/@itemx/@item/


Thanks Andreas and Jim.
Updated patch attached.

cheers,
Pádraig.
From ae757472419a8c3a08e871114d941d7feed7945f Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
Date: Mon, 6 Apr 2009 19:21:51 +0100
Subject: [PATCH] doc: add missing documentation for some SELinux options

* doc/coreutils.texi (ls invocation): Describe the --context (-Z) option
(install invocation): Describe the --preserve-context and -Z options
(id invocation): Describe the --context (-Z) option
(mkdir invocation): ditto
(mknod invocation): ditto
(mkfifo invocation): ditto
* TODO: remove the todo item
---
 TODO   |1 -
 doc/coreutils.texi |   64 
 2 files changed, 64 insertions(+), 1 deletions(-)

diff --git a/TODO b/TODO
index 7288285..9128ddf 100644
--- a/TODO
+++ b/TODO
@@ -15,7 +15,6 @@ document the following in coreutils.texi:
   mktemp
   [
   pinky
-Also document the SELinux changes.
 
 Suggestion from Paul Eggert:
   More generally, there's not that much use for imaxtostr nowadays,
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 70effa1..0e547a1 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -6540,6 +6540,16 @@ it also affects the HP-UX @command{ls} program.
 
 @optSi
 
+...@item -Z
+...@itemx --context
+...@opindex -Z
+...@opindex --context
+...@cindex SELinux
+...@cindex security context
+Display the SELinux security context or @samp{?} if none is found. When used
+with the @option{-l} option, print the security context to the left of the
+size column.
+
 @end table
 
 
@@ -8045,6 +8055,15 @@ ownership of installed files or directories to @var{owner}.  The default
 is @code{root}.  @var{owner} may be either a user name or a numeric user
 ID.
 
+...@item --preserve-context
+...@opindex --preserve-context
+...@cindex SElinux
+...@cindex security context
+Preserve the SELinux security context of files and directories.
+Failure to preserve the context in all of the files or directories
+will result in an exit status of 1. If SELinux is disabled then
+a warning is printed and the option is ignored.
+
 @item -p
 @itemx --preserve-timestamps
 @opindex -p
@@ -8083,6 +8102,16 @@ Program used to strip binaries.
 @opindex --verbose
 Print the name of each file before copying it.
 
+...@item -Z @var{context}
+...@itemx --conte...@var{context}
+...@opindex -Z
+...@opindex --context
+...@cindex SELinux
+...@cindex security context
+Set the default SELinux security context to be used for any
+created files and directories. If SELinux is disabled then
+print a warning and ignore the option.
+
 @end table
 
 @exitstatus
@@ -8917,6 +8946,15 @@ newly-created parent directories are inherited.
 @opindex --verbose
 Print a message for each created directory.  This is most useful with
 @option{--parents}.
+
+...@item -Z @var{context}
+...@itemx --conte...@var{context}
+...@opindex -Z
+...@opindex --context
+...@cindex SELinux
+...@cindex security context
+Set the default SELinux security context to be used for created directories.
+
 @end table
 
 @exitstatus
@@ -8956,6 +8994,14 @@ Set the mode of created FIFOs to @var{mode}, which is symbolic as in
 for the point of departure.  @var{mode} should specify only file
 permission bits.  @xref{File permissions}.
 
+...@item -Z @var{context}
+...@itemx --conte...@var{context}
+...@opindex -Z
+...@opindex --context
+...@cindex SELinux
+...@cindex security context
+Set the default SELinux security context to be used for created FIFOs.
+
 @end table
 
 @exitstatus
@@ -9031,6 +9077,14 @@ Set the mode of created files to @var{mode}, which is symbolic as in
 @var{mode} should specify only file permission bits.
 @xref{File permissions}.
 
+...@item -Z @var{context}
+...@itemx --conte...@var{context}
+...@opindex -Z
+...@opindex --context
+...@cindex SELinux
+...@cindex security context
+Set the default SELinux security context to be used for created files.
+
 @end table
 
 @exitstatus
@@ -12737,6 +12791,16 @@ Print the real, instead of effective, user or group ID.  Requires
 @opindex --user
 Print only the user ID.
 
+...@item -Z
+...@itemx --context
+...@opindex -Z
+...@opindex --context
+...@cindex SELinux
+...@cindex security context
+Print only the security context of the current user.
+If SELinux is disabled then print a warning and
+set the exit status to 1.
+
 @end table
 
 @exitstatus
-- 
1.5.3.6

___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: RFC: changing the + in ls -l output to be . or +

2009-04-07 Thread Jim Meyering
Pádraig Brady wrote:
 Updated patch attached.

One more, please ;-)

 +...@item --preserve-context
 +...@opindex --preserve-context
 +...@cindex SElinux
 +...@cindex security context
 +Preserve the SELinux security context of files and directories.
 +Failure to preserve the context in all of the files or directories
 +will result in an exit status of 1. If SELinux is disabled then
 +a warning is printed and the option is ignored.

s/...is printed and is ignored/ print a warning and ignore the option


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: RFC: changing the + in ls -l output to be . or +

2009-04-06 Thread Pádraig Brady
Jim Meyering wrote:
 You might want to do something similar to what I did in fts.c
 with this change:
 
 http://git.sv.gnu.org/cgit/gnulib.git/commit/?id=97d5b66578be507

Oh cool, thanks for that.
I'll also look at documenting the ls SElinux options in the info docs
as I couldn't see them on a quick search.

cheers,
Pádraig.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: RFC: changing the + in ls -l output to be . or +

2009-04-06 Thread Jim Meyering
Pádraig Brady wrote:
...
 I'll also look at documenting the ls SElinux options in the info docs
 as I couldn't see them on a quick search.

Nice.  That will we welcome.
If you feel really industrious, mktemp needs info documentation, too.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: RFC: changing the + in ls -l output to be . or +

2009-04-06 Thread Jim Meyering
Pádraig Brady wrote:
 Just a quick follow up to this now archived bug:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472590

 The last message there mentioned selinux query overhead.
 On my system with selinux disabled, there is currently
 a significant overhead in doing the selinux lookup per file
 with a standard `ls -l` listing.
 A quick test shows that I can list 100K files in 0.9s
 with the selinux lookup commented out, while it increases
 to 1.3s when the lookup is done.

 I'm not sure how selinux works TBH, but it was mentioned
 in the bug that if it's in one file then it's in all.
 If this was always true then the selinux lookup would only
 need to be done for the first file in the listing?
 If not, then perhaps some caching could be added to
 at least indicate quickly that selinux is disabled on
 the current (file) system.

 I know speed isn't that important for ls but it would be nice
 to get back the 40% slow down if possible.

Sounds worthwhile.
AFAIK, you can assume that on a given partition (stat.st_dev),
that attribute (SELinux-affected) is the same for every file.

You might want to do something similar to what I did in fts.c
with this change:

http://git.sv.gnu.org/cgit/gnulib.git/commit/?id=97d5b66578be507

There, I associated each device number encountered with a boolean
indicating whether leaf-optimization works on it.

In ls.c, you'd maintain a map to associate st_dev - bool selinux_enabled.
You'd need slightly less code than in fts.c, since you won't need to
create/use new struct members.  A global hash table would be sufficient.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: RFC: changing the + in ls -l output to be . or +

2009-04-02 Thread Pádraig Brady
Just a quick follow up to this now archived bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472590

The last message there mentioned selinux query overhead.
On my system with selinux disabled, there is currently
a significant overhead in doing the selinux lookup per file
with a standard `ls -l` listing.
A quick test shows that I can list 100K files in 0.9s
with the selinux lookup commented out, while it increases
to 1.3s when the lookup is done.

I'm not sure how selinux works TBH, but it was mentioned
in the bug that if it's in one file then it's in all.
If this was always true then the selinux lookup would only
need to be done for the first file in the listing?
If not, then perhaps some caching could be added to
at least indicate quickly that selinux is disabled on
the current (file) system.

I know speed isn't that important for ls but it would be nice
to get back the 40% slow down if possible.

cheers,
Pádraig.



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: RFC: changing the + in ls -l output to be . or +

2008-10-31 Thread Daniel J Walsh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim Meyering wrote:
 Russell Coker [EMAIL PROTECTED] wrote:
 
 On Saturday 25 October 2008 00:19, Mike Edenfield [EMAIL PROTECTED] 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.
 
 --
 This message was distributed to subscribers of the selinux mailing list.
 If you no longer wish to subscribe, send mail to [EMAIL PROTECTED] with
 the words unsubscribe selinux without quotes as the message.
If you really wanted to go wild, you could add a qualifier to check
matchpathcon to indicate it differs from the default for the file
system, although it would be very expensive.  Perhaps find would be a
better source.  find all files not matching the system defaults.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkLCjEACgkQrlYvE4MpobM3ywCfZtVW9cQE8hgLRVCHYqHKLfU1
cWgAn2/cx41bmoFguBEVJXGbUiqsryzH
=+qTw
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: Bug#472590: RFC: changing the + in ls -l output to be . or +

2008-10-27 Thread Michael Stone

On Fri, Oct 24, 2008 at 09:19:07AM -0400, Mike Edenfield wrote:
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?


It buys something if you're unaware that selinux is enabled on the 
system and you can't understand why you can't do something even though 
the file permissions say you should be able to. That's the whole point 
of havin an alternate-acl indicator--so you know when looking at the 
permissions that they aren't the whole story. One thing about selinux 
users is that they sometimes forget that some people aren't...


Mike Stone


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: RFC: changing the + in ls -l output to be . or +

2008-10-26 Thread Russell Coker
On Saturday 25 October 2008 00:19, Mike Edenfield [EMAIL PROTECTED] 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.

-- 
Russell Coker [EMAIL PROTECTED]
http://etbe.coker.com.au/  My Blog
http://etbe.coker.com.au/category/security/  My Security blog posts
http://www.coker.com.au/selinux/play.html  My Play Machine, root PW SELINUX


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: RFC: changing the + in ls -l output to be . or +

2008-10-26 Thread Jim Meyering
Russell Coker [EMAIL PROTECTED] wrote:

 On Saturday 25 October 2008 00:19, Mike Edenfield [EMAIL PROTECTED] 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.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: RFC: changing the + in ls -l output to be . or +

2008-10-24 Thread Jim Meyering
Vikram Noel Ambrose [EMAIL PROTECTED] wrote:
 Jim Meyering [EMAIL PROTECTED] wrote:
...
 if (SELinux, with no other MAC or ACL)
   use '.'
 else if (any other combination of alternate access methods)
   use '+'
...
 Here's sample output, running on an SELinux system:

   $ src/ls -ldgo [ac]*
   -rw-r--r--.  1   42625 2008-04-02 19:31 aclocal.m4
   drwxr-xr-x.  24096 2008-04-02 19:31 autom4te.cache
   -rw-r--r--.  11597 2008-03-21 16:35 cfg.mk
   -rw-r--r--.  1 1417195 2008-04-02 19:33 config.log
   -rwxr-xr-x.  1   71225 2008-04-02 19:33 config.status
   -rwxr-xr-x.  1 1846424 2008-04-02 19:31 configure
   -rw-r--r--.  1   12014 2008-03-25 23:55 configure.ac


 This is so confusing. What is so horribly wrong with a capital S for
 SELinux or A for ACL?

A desire for compatibility makes + look good.
. is appealing for SELinux-only because it's inconspicuous.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: RFC: changing the + in ls -l output to be . or +

2008-10-24 Thread Mike Edenfield

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.


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 +






___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: RFC: changing the + in ls -l output to be . or +

2008-10-24 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Mike Edenfield on 10/24/2008 7:19 AM:
 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  

Unfortunately, that would violate POSIX, which requires ' ' in the case
when no alternate access controls are in force.  And SELinux contexts
count as an alternate access control.

The optional alternate access method flag shall be a single space if
there is no alternate or additional access control method associated with
the file; otherwise, a printable character shall be used.
http://www.opengroup.org/onlinepubs/009695399/utilities/ls.html

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkBzw8ACgkQ84KuGfSFAYCXAACeN4uUaHlCuBXUMFeJLsBDyShJ
AGIAniTtjas6Urnz/P92Vhr/JFx19oZC
=ibH3
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: RFC: changing the + in ls -l output to be . or +

2008-10-23 Thread Jim Meyering
Jim Meyering [EMAIL PROTECTED] wrote:
 I wrote this:
 [ I'm Cc'ing [EMAIL PROTECTED]
   FYI, this is a continuation of discussion from the SELinux list:
   http://marc.info/?t=12064507403r=1w=2
   and the debian bug tracking system: http://bugs.debian.org/472590

   The problem is that on an SELinux-enabled system, 'ls -l's +,
   the alternate access method indicator, is useless, because it
   appears on every file:

   $ ls -glo /var
   total 164
   drwxr-xr-x+  3 4096 2008-03-29 08:43 kerberos
   drwxr-xr-x+ 39 4096 2008-03-29 08:43 lib
   drwxr-xr-x+  2 4096 2008-03-27 17:33 local
   drwxrwxr-x+  8 4096 2008-03-31 04:15 lock
   drwxr-xr-x+ 20 4096 2008-03-31 09:55 log
   lrwxrwxrwx+  1   10 2008-03-28 23:33 mail - spool/mail
   ...

   Newer POSIX allows any non-space character as the indicator, and
   that's what we're discussing now.
   ]

 Russell Coker [EMAIL PROTECTED] wrote:
 On Wednesday 26 March 2008 04:31, Michael Stone [EMAIL PROTECTED] wrote:
 if (acl) then '+'
 else if (selinux) then '.'

 Should there be some special marking of files with both a SE Linux context 
 and
 an ACL?

 Pity that they didn't choose an a to mark an ACL which would then permit
 using A for ACL + MAC.

 This is probably as good a time as any to make such a change, though
 I doubt it will make the cut for the upcoming release.  I'd like to keep
 it simple (i.e., not try to encode all possible combinations).  If you
 want to get full details, stat(1) is probably the program to change.

 I like Michael's suggestion.  Rephrasing it,

 if (SELinux, with no other MAC or ACL)
   use '.'
 else if (any other combination of alternate access methods)
   use '+'

 If someone who already has a copyright assignment on file for coreutils
 wants to write the patch (including doc update, tests, NEWS, ChangeLog,
 etc.), please speak up ASAP.  Otherwise I'll do it.

 No one spoke up, so here's code, for discussion's sake.
 I've tested it only lightly.
 This change is not slated for the upcoming release.

 Here's sample output, running on an SELinux system:

   $ src/ls -ldgo [ac]*
   -rw-r--r--.  1   42625 2008-04-02 19:31 aclocal.m4
   drwxr-xr-x.  24096 2008-04-02 19:31 autom4te.cache
   -rw-r--r--.  11597 2008-03-21 16:35 cfg.mk
   -rw-r--r--.  1 1417195 2008-04-02 19:33 config.log
   -rwxr-xr-x.  1   71225 2008-04-02 19:33 config.status
   -rwxr-xr-x.  1 1846424 2008-04-02 19:31 configure
   -rw-r--r--.  1   12014 2008-03-25 23:55 configure.ac

Thanks to a nudge from Ondřej, I've just completed and pushed this:

From b3677e5e383103bf1764b2c8a9329b1c17934b24 Mon Sep 17 00:00:00 2001
From: Jim Meyering [EMAIL PROTECTED]
Date: Wed, 2 Apr 2008 22:26:45 +0200
Subject: [PATCH] ls: use '.' (not +) as SELinux-only alt. access flag in ls -l 
output

* src/ls.c (gobble_file) [long_format]: Map SELinux-only to '.',
any other nonempty combination of MAC and ACL to '+', and all else
to the usual ' '.  Suggested by Michael Stone.
* tests/misc/selinux: Adapt: expect '.', not '+'.
* doc/coreutils.texi (What information is listed): Document this.
* NEWS (Changes in behavior): Mention it.
---
 NEWS   |6 ++
 doc/coreutils.texi |8 +---
 src/ls.c   |   25 +++--
 tests/misc/selinux |4 ++--
 4 files changed, 32 insertions(+), 11 deletions(-)

diff --git a/NEWS b/NEWS
index ab7d5bd..357efc2 100644
--- a/NEWS
+++ b/NEWS
@@ -6,6 +6,12 @@ GNU coreutils NEWS-*- 
outline -*-

   stat -f recognizes the Lustre file system type

+** Changes in behavior
+
+  ls -l now marks SELinux-only files with the less obtrusive '.',
+  rather than '+'.  A file with any other combination of MAC and ACL
+  is still marked with a '+'.
+

 * Noteworthy changes in release 7.0 (2008-10-05) [beta]

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 6459870..cbef013 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -6474,9 +6474,11 @@ What information is listed
 space, there is no alternate access method.  When it is a printing
 character, then there is such a method.

-For a file with an extended access control list, a @samp{+} character is
-listed.  Basic access control lists are equivalent to the permissions
-listed, and are not considered an alternate access method.
+GNU @command{ls} uses a @samp{.} character to indicate a file
+with an SELinux security context, but no other alternate access method.
+
+A file with any other combination of alternate access methods
+is marked with a @samp{+} character.

 @item -n
 @itemx --numeric-uid-gid
diff --git a/src/ls.c b/src/ls.c
index e38a5fe..590af7f 100644
--- a/src/ls.c
+++ b/src/ls.c
@@ -154,6 +154,12 @@ verify (sizeof filetype_letter - 1 == arg_directory + 1);
 C_LINK, C_SOCK, C_FILE, C_DIR  \
   }

+enum acl_type
+  {
+ACL_T_NONE,
+ACL_T_SELINUX_ONLY,
+ACL_T_YES
+  };

 struct fileinfo
   {
@@ -182,7 +188,7 @@ struct 

Re: RFC: changing the + in ls -l output to be . or +

2008-10-23 Thread Vikram Noel Ambrose

Jim Meyering [EMAIL PROTECTED] wrote:

[ I'm Cc'ing [EMAIL PROTECTED]
  FYI, this is a continuation of discussion from the SELinux list:
  http://marc.info/?t=12064507403r=1w=2
  and the debian bug tracking system: http://bugs.debian.org/472590

  The problem is that on an SELinux-enabled system, 'ls -l's +,
  the alternate access method indicator, is useless, because it
  appears on every file:

  $ ls -glo /var
  total 164
  drwxr-xr-x+  3 4096 2008-03-29 08:43 kerberos
  drwxr-xr-x+ 39 4096 2008-03-29 08:43 lib
  drwxr-xr-x+  2 4096 2008-03-27 17:33 local
  drwxrwxr-x+  8 4096 2008-03-31 04:15 lock
  drwxr-xr-x+ 20 4096 2008-03-31 09:55 log
  lrwxrwxrwx+  1   10 2008-03-28 23:33 mail - spool/mail
  ...

  Newer POSIX allows any non-space character as the indicator, and
  that's what we're discussing now.
  ]

Russell Coker [EMAIL PROTECTED] wrote:
  

On Wednesday 26 March 2008 04:31, Michael Stone [EMAIL PROTECTED] wrote:


if (acl) then '+'
else if (selinux) then '.'
  

Should there be some special marking of files with both a SE Linux context and
an ACL?

Pity that they didn't choose an a to mark an ACL which would then permit
using A for ACL + MAC.


This is probably as good a time as any to make such a change, though
I doubt it will make the cut for the upcoming release.  I'd like to keep
it simple (i.e., not try to encode all possible combinations).  If you
want to get full details, stat(1) is probably the program to change.

I like Michael's suggestion.  Rephrasing it,

if (SELinux, with no other MAC or ACL)
  use '.'
else if (any other combination of alternate access methods)
  use '+'

If someone who already has a copyright assignment on file for coreutils
wants to write the patch (including doc update, tests, NEWS, ChangeLog,
etc.), please speak up ASAP.  Otherwise I'll do it.
  

No one spoke up, so here's code, for discussion's sake.
I've tested it only lightly.
This change is not slated for the upcoming release.

Here's sample output, running on an SELinux system:

  $ src/ls -ldgo [ac]*
  -rw-r--r--.  1   42625 2008-04-02 19:31 aclocal.m4
  drwxr-xr-x.  24096 2008-04-02 19:31 autom4te.cache
  -rw-r--r--.  11597 2008-03-21 16:35 cfg.mk
  -rw-r--r--.  1 1417195 2008-04-02 19:33 config.log
  -rwxr-xr-x.  1   71225 2008-04-02 19:33 config.status
  -rwxr-xr-x.  1 1846424 2008-04-02 19:31 configure
  -rw-r--r--.  1   12014 2008-03-25 23:55 configure.ac



This is so confusing. What is so horribly wrong with a capital S for 
SELinux or A for ACL?


Vikram


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


RFC: changing the + in ls -l output to be . or +

2008-04-02 Thread Jim Meyering
I wrote this:
 [ I'm Cc'ing [EMAIL PROTECTED]
   FYI, this is a continuation of discussion from the SELinux list:
   http://marc.info/?t=12064507403r=1w=2
   and the debian bug tracking system: http://bugs.debian.org/472590

   The problem is that on an SELinux-enabled system, 'ls -l's +,
   the alternate access method indicator, is useless, because it
   appears on every file:

   $ ls -glo /var
   total 164
   drwxr-xr-x+  3 4096 2008-03-29 08:43 kerberos
   drwxr-xr-x+ 39 4096 2008-03-29 08:43 lib
   drwxr-xr-x+  2 4096 2008-03-27 17:33 local
   drwxrwxr-x+  8 4096 2008-03-31 04:15 lock
   drwxr-xr-x+ 20 4096 2008-03-31 09:55 log
   lrwxrwxrwx+  1   10 2008-03-28 23:33 mail - spool/mail
   ...

   Newer POSIX allows any non-space character as the indicator, and
   that's what we're discussing now.
   ]

 Russell Coker [EMAIL PROTECTED] wrote:
 On Wednesday 26 March 2008 04:31, Michael Stone [EMAIL PROTECTED] wrote:
 if (acl) then '+'
 else if (selinux) then '.'

 Should there be some special marking of files with both a SE Linux context 
 and
 an ACL?

 Pity that they didn't choose an a to mark an ACL which would then permit
 using A for ACL + MAC.

 This is probably as good a time as any to make such a change, though
 I doubt it will make the cut for the upcoming release.  I'd like to keep
 it simple (i.e., not try to encode all possible combinations).  If you
 want to get full details, stat(1) is probably the program to change.

 I like Michael's suggestion.  Rephrasing it,

 if (SELinux, with no other MAC or ACL)
   use '.'
 else if (any other combination of alternate access methods)
   use '+'

 If someone who already has a copyright assignment on file for coreutils
 wants to write the patch (including doc update, tests, NEWS, ChangeLog,
 etc.), please speak up ASAP.  Otherwise I'll do it.

No one spoke up, so here's code, for discussion's sake.
I've tested it only lightly.
This change is not slated for the upcoming release.

Here's sample output, running on an SELinux system:

  $ src/ls -ldgo [ac]*
  -rw-r--r--.  1   42625 2008-04-02 19:31 aclocal.m4
  drwxr-xr-x.  24096 2008-04-02 19:31 autom4te.cache
  -rw-r--r--.  11597 2008-03-21 16:35 cfg.mk
  -rw-r--r--.  1 1417195 2008-04-02 19:33 config.log
  -rwxr-xr-x.  1   71225 2008-04-02 19:33 config.status
  -rwxr-xr-x.  1 1846424 2008-04-02 19:31 configure
  -rw-r--r--.  1   12014 2008-03-25 23:55 configure.ac



Use '.' (not +) as SELinux-only alternate access flag in ls -l output
* src/ls.c (gobble_file) [long_format]: Map SELinux-only to '.',
any other nonempty combination of MAC and ACL to '+', and all else
to the usual ' '.
* tests/misc/selinux: Adapt: expect '.', not '+'.
* NEWS: TBD

---
 src/ls.c   |   25 +++--
 tests/misc/selinux |4 ++--
 2 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/src/ls.c b/src/ls.c
index e029fe0..ae234da 100644
--- a/src/ls.c
+++ b/src/ls.c
@@ -151,6 +151,12 @@ verify (sizeof filetype_letter - 1 == arg_directory + 1);
 C_LINK, C_SOCK, C_FILE, C_DIR  \
   }

+enum acl_type
+  {
+ACL_T_NONE,
+ACL_T_SELINUX_ONLY,
+ACL_T_YES
+  };

 struct fileinfo
   {
@@ -179,7 +185,7 @@ struct fileinfo

 /* For long listings, true if the file has an access control list,
or an SELinux security context.  */
-bool have_acl;
+enum acl_type acl_type;
   };

 #define LEN_STR_PAIR(s) sizeof (s) - 1, s
@@ -2671,6 +2677,7 @@ gobble_file (char const *name, enum filetype type, ino_t 
inode,

   if (format == long_format || print_scontext)
{
+ bool have_selinux = false;
  bool have_acl = false;
  int attr_len = (do_deref
  ?  getfilecon (absolute_name, f-scontext)
@@ -2689,7 +2696,7 @@ gobble_file (char const *name, enum filetype type, ino_t 
inode,
}

  if (err == 0)
-   have_acl = ! STREQ (unlabeled, f-scontext);
+   have_selinux = ! STREQ (unlabeled, f-scontext);
  else
{
  f-scontext = UNKNOWN_SECURITY_CONTEXT;
@@ -2702,15 +2709,19 @@ gobble_file (char const *name, enum filetype type, 
ino_t inode,
err = 0;
}

- if (err == 0  ! have_acl  format == long_format)
+ if (err == 0  format == long_format)
{
  int n = file_has_acl (absolute_name, f-stat);
  err = (n  0);
  have_acl = (0  n);
}

- f-have_acl = have_acl;
- any_has_acl |= have_acl;
+ f-acl_type = (!have_selinux  !have_acl
+? ACL_T_NONE
+: (have_selinux  !have_acl
+   ? ACL_T_SELINUX_ONLY
+   : ACL_T_YES));
+ any_has_acl |= f-acl_type != ACL_T_NONE;

  if (err)
error