findutils-4.2.15

[Tim Waugh]

Hi,

I just updated findutils to 4.2.15 in devel.  Please check that I
didn't make any mistakes porting the findutils-selinux.patch.

Thanks,
Tim.
*/

[Russell Coker]

On Tuesday 01 February 2005 01:48, Tim Waugh <twaugh(a)redhat.com&gt; wrote:
>  I just updated findutils to 4.2.15 in devel.  Please check that I
>  didn't make any mistakes porting the findutils-selinux.patch. 
I can't comment on the changes as I never tested the old version.  Here are 
some suggestions about the current version:

getfilecon(/proc/2/maps): Operation not supported

Above is part of the output of "find / --context system_u:object_r:bin_t".  
Perhaps it would make sense that whenever find enters a new file system it 
checks whether the context is available and skips file systems of types that 
don't support the XATTR interface to labelling.  We could have a config file 
which lists the supported file systems (ext2, ext3, xfs, devpts, and tmpfs at 
the moment) so that find knows what to do.  Or maybe this is something that 
should be in the kernel?  Another option might be to just have find give up 
on a tree when a directory gives ENOTSUP.

Searching on context alone seems of little utility to me.  I think it's likely 
that most times when a search is being performed the desired result will 
either be all files of a particular identity or of a particular type.  For 
example I may want to find files of type bin_t to discover the full list of 
programs that can_exec(foo_t, bin_t) grants access to.  The fact that I 
created some files under /usr/local/bin by just copying them there as 
administrator (and giving them the context of root:object_r:bin_t instead of 
the usual system_u:object_r:bin_t) not something that concerns me.

Also saving some typing is a benefit too.  When running chcon I often use the 
-t option to save typing as usually I only want to change the type and am not 
concerned about the identity.

The command `find . -printf "%Z %f\n"` returns the string "pipefs"
instead of 
the final "t" in file contexts.  Eg here's part of the output of running
such 
a find command from the /var/run directory:
system_u:object_r:xdm_var_run_pipefs gdm.pid

Here's "ls -lZ" output from the same file:
-rw-r--r--  root     root     system_u:object_r:xdm_var_run_t  gdm.pid

Once again, being able to split out identity and type would be handy, the 
-printf option has a huge number of ways of specifying atime with %A, maybe 
having %Zi for identity, %Zt for type, and %z for full context would be a 
good idea.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

[Daniel J Walsh]

Russell Coker wrote:

> On Tuesday 01 February 2005 01:48, Tim Waugh <twaugh(a)redhat.com&gt;
> wrote:
>   
>
> >I just updated findutils to 4.2.15 in devel.  Please check that I
> >didn't make any mistakes porting the findutils-selinux.patch.
> >    
> >
>
> I can't comment on the changes as I never tested the old version.  Here are 
> some suggestions about the current version:
>
> getfilecon(/proc/2/maps): Operation not supported
>
> Above is part of the output of "find / --context system_u:object_r:bin_t".  
> Perhaps it would make sense that whenever find enters a new file system it 
> checks whether the context is available and skips file systems of types that 
> don't support the XATTR interface to labelling.  We could have a config file 
> which lists the supported file systems (ext2, ext3, xfs, devpts, and tmpfs at 
> the moment) so that find knows what to do.  Or maybe this is something that 
> should be in the kernel?  Another option might be to just have find give up 
> on a tree when a directory gives ENOTSUP.
>
> Searching on context alone seems of little utility to me.  I think it's likely 
> that most times when a search is being performed the desired result will 
> either be all files of a particular identity or of a particular type.  For 
> example I may want to find files of type bin_t to discover the full list of 
> programs that can_exec(foo_t, bin_t) grants access to.  The fact that I 
> created some files under /usr/local/bin by just copying them there as 
> administrator (and giving them the context of root:object_r:bin_t instead of 
> the usual system_u:object_r:bin_t) not something that concerns me.
>
> Also saving some typing is a benefit too.  When running chcon I often use the 
> -t option to save typing as usually I only want to change the type and am not 
> concerned about the identity.
>   
>  
Find has glob support to do something similar
so you can

find / --context *:bin_t

to find all bin_t files.


> The command `find . -printf "%Z %f\n"` returns the string
> "pipefs" instead of 
> the final "t" in file contexts.  Eg here's part of the output of running
> such 
> a find command from the /var/run directory:
> system_u:object_r:xdm_var_run_pipefs gdm.pid
>
> Here's "ls -lZ" output from the same file:
> -rw-r--r--  root     root     system_u:object_r:xdm_var_run_t  gdm.pid
>
> Once again, being able to split out identity and type would be handy, the 
> -printf option has a huge number of ways of specifying atime with %A, maybe 
> having %Zi for identity, %Zt for type, and %z for full context would be a 
> good idea.
>
>   
>