[PATCH] Add SELinux support

[Kamil Dudka]

Hello,

proposed patch for GNU find adding SELinux support (-context predicate
and %Z printf directive) is attached. Patch like this has been already 
proposed on the list: 
http://lists.gnu.org/archive/html/bug-findutils/2005-11/msg00079.html
and discussed again at bug-coreutils:
http://lists.gnu.org/archive/html/bug-coreutils/2008-11/msg00017.html

The SELinux support is already in Fedora findutils for a long time. Proposed 
patch is modified to use gnulib module selinux-h which adds selinux/selinux.h 
header on systems that lack it.


Kamil
From 2212fcc63960ac417f161ac6a3a29367385ad65a Mon Sep 17 00:00:00 2001
From: Kamil Dudka kdu...@redhat.com
Date: Wed, 28 Jan 2009 15:00:34 +0100
Subject: [PATCH] Add SELinux support.

* find/defs.h: Add SELinux definitions.
* find/tree.c: Add -context predicate to lookup.
* find/pred.c: Handle %Z printf directive.
* find/parser.c: Parse -context predicate and %Z printf directive.
* find/find.1: Mention -context predicate and %Z printf directive.
* doc/find.texi: Mention -context predicate and %Z printf directive.
* find/Makefile.am: Add SELinux libraries.
* import-gnulib.config: Require gnulib module selinux-h.
---
 doc/find.texi|   10 
 find/Makefile.am |2 +-
 find/defs.h  |6 +++
 find/find.1  |4 ++
 find/parser.c|  119 +-
 find/pred.c  |   38 
 find/tree.c  |4 +-
 import-gnulib.config |1 +
 8 files changed, 180 insertions(+), 4 deletions(-)

diff --git a/doc/find.texi b/doc/find.texi
index 56d3e32..242ff42 100644
--- a/doc/find.texi
+++ b/doc/find.texi
@@ -1242,6 +1242,14 @@ situation.
 
 @end deffn
 
+...@deffn Test -context pattern
+True if file's SELinux context matches the pattern @var{pattern}.
+The pattern uses shell glob matching.
+
+This predicate is supported only on @code{find} versions compiled with
+SELinux support and only when SELinux is enabled.
+...@end deffn
+
 @node Contents
 @section Contents
 
@@ -1826,6 +1834,8 @@ value used for BLOCKSIZE is system-dependent, but is usually 512
 bytes.  If the file size is zero, the value printed is undefined.  On
 systems which lack support for st_blocks, a file's sparseness is
 assumed to be 1.0.
+...@item %Z
+File's SELinux context, or empty string if the file has no SELinux context.
 @end table
 
 @node Location Directives
diff --git a/find/Makefile.am b/find/Makefile.am
index b001509..6fc7df3 100644
--- a/find/Makefile.am
+++ b/find/Makefile.am
@@ -26,7 +26,7 @@ endif
 
 EXTRA_DIST = defs.h $(man_MANS)
 INCLUDES = -I../gnulib/lib -I$(top_srcdir)/lib -I$(top_srcdir)/gnulib/lib -I../intl -DLOCALEDIR=\$(localedir)\
-LDADD = ./libfindtools.a ../lib/libfind.a ../gnulib/lib/libgnulib.a @INTLLIBS@ @LIB_CLOCK_GETTIME@ @FINDLIBS@
+LDADD = ./libfindtools.a ../lib/libfind.a ../gnulib/lib/libgnulib.a @INTLLIBS@ @LIB_CLOCK_GETTIME@ @FINDLIBS@ @LIB_SELINUX@
 man_MANS = find.1
 SUBDIRS = . testsuite
 
diff --git a/find/defs.h b/find/defs.h
index 1708d83..4c4e1b1 100644
--- a/find/defs.h
+++ b/find/defs.h
@@ -48,6 +48,7 @@ Please stop compiling the program now
 #include stdbool.h		/* for bool/boolean */
 #include stdint.h		/* for uintmax_t */
 #include sys/stat.h /* S_ISUID etc. */
+#include selinux/selinux.h
 
 
 
@@ -315,6 +316,7 @@ struct predicate
 struct samefile_file_id samefileid; /* samefile */
 mode_t type;		/* type */
 struct format_val printf_vec; /* printf fprintf fprint ls fls print0 fprint0 print */
+security_context_t scontext; /* scontext */
   } args;
 
   /* The next predicate in the user input sequence,
@@ -459,6 +461,7 @@ PREDICATEFUNCTION pred_used;
 PREDICATEFUNCTION pred_user;
 PREDICATEFUNCTION pred_writable;
 PREDICATEFUNCTION pred_xtype;
+PREDICATEFUNCTION pred_context;
 
 
 
@@ -601,6 +604,9 @@ struct options
*/
   int regex_options;
 
+  /* function used to get file context */
+  int (*x_getfilecon) ();
+
   /* Optimisation level.  One is the default. 
*/
   unsigned short optimisation_level;
diff --git a/find/find.1 b/find/find.1
index 25953fc..52c8017 100644
--- a/find/find.1
+++ b/find/find.1
@@ -933,6 +933,8 @@ if \fIc\fR is `l'.  In other words, for symbolic links,
 checks the type of the file that 
 .B \-type
 does not check.
+.IP \-context \fIpattern\fR
+(SELinux only) Security context of the file matches glob \fIpattern\fR.
 
 .SS ACTIONS
 .IP \-delete\fR
@@ -1354,6 +1356,8 @@ File's type (like in
 U=unknown type (shouldn't happen)
 .IP %Y
 File's type (like %y), plus follow symlinks: L=loop, N=nonexistent
+.IP %Z
+(SELinux only) file's security context.
 .PP
 A `%' character followed by any other character is discarded, but the
 other character is printed (don't rely on this, as further format
diff --git a/find/parser.c b/find/parser.c
index 7f404ba..4fc43f8 100644
--- a/find/parser.c
+++ b/find/parser.c
@@ -53,6 +53,8 @@
 #include unistd.h 
 #include sys/stat.h
 
+#include selinux/selinux.h
+
 #if ENABLE_NLS
 # include

[patch #4848] Patch - Support for SELinux

[Kamil Dudka]

Additional Item Attachment, patch #4848 (project findutils):

File name: 0001-Add-SELinux-support.patch Size:14 KB


___

Reply to this item at:

  http://savannah.gnu.org/patch/?4848

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[patch #4848] Patch - Support for SELinux

[Kamil Dudka]

Additional Item Attachment, patch #4848 (project findutils):

File name: 0001-find-add-SELinux-support.patch Size:14 KB


___

Reply to this item at:

  http://savannah.gnu.org/patch/?4848

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[patch #4848] Patch - Support for SELinux

[Kamil Dudka]

Follow-up Comment #4, patch #4848 (project findutils):

 * It does not update the Texinfo documentation at all!
It does. The -context predicate is mentioned in 'info Finding Files Mode
Bits' and the %Z printf conversion is mentioned in 'info Actions Print
File Information Format Directives Size Directives' which is actually a
wrong place. But I can't see any suitable node to move it. Should we create
separate node for security context?

 * It makes --version emit SELINUX even if that feature is not availble.
 This is especially a problem because now there is presumably a significant
 installed base of RH-related machines that give misleading information. 
 Since the gnulib implementation is a stub even if the compiled program is
 then run on a SELinux-enabled system, this is an unfortunate bug.  If a
 binary RPM package made with this patch has never been built on a machine
 lacking the selinux development libraries, this may be a bug without
impact
 though.
available.
I've changed it to check for SELinux in run-time.

 * The costlookup[] initialisation sets pred_context to NeedsNothing, which
 will presumably lead the optimiser to prefer it to much cheaper tests (for
 example -type).  I would guess that NeedsAccessInfo is probably
 approximately the right cost (though I have not looked at the SELinux
 implementation).
I've looked quickly into getfilecon implementation. It uses the getxattr
function to obtain file's context which uses getxattr syscall, at least at
Fedora. The implementation is probably file system dependent, but
NeedsAccessInfo seems to be good candidate.

 * parse_context leaves pred-est_success_rate at 1.0, which is on average
 an overestimate.
Well, changed to 0.01 - is this ok?

 There are also some minor issues which are just not a big deal (not
 patching the NEWS or ChangeLog files, spurious introduction of
 pred-args.scontext).
I've attempted to fix these minor issues.


___

Reply to this item at:

  http://savannah.gnu.org/patch/?4848

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [PATCH 1/2] find: add SELinux support

[Kamil Dudka]

On Saturday 11 of July 2009 17:05:18 James Youngman wrote:
 From: Kamil Dudka kdu...@redhat.com

 * find/defs.h: Add SELinux related definitions.
 * find/tree.c: Add -context predicate to lookup.
 * find/pred.c: Handle %Z printf directive.
 * find/parser.c: Parse -context predicate and %Z printf directive.
 * find/find.1: Mention -context predicate and %Z printf directive.
 * doc/find.texi: Mention -context predicate and %Z printf directive.
 * find/Makefile.am: Add SELinux libraries.
 * import-gnulib.config: Require gnulib module selinux-h.

Thanks for digging up the SELinux patch!

Kamil

Re: [PATCH 1/2] find: add SELinux support

[Kamil Dudka]

On Sat July 11 2009 18:10:49 James Youngman wrote:
 On Sat, Jul 11, 2009 at 4:58 PM, Kamil Dudkakdu...@redhat.com wrote:
  Thanks for digging up the SELinux patch!

 No problem.   From memory, I think the SELinux kernel support in
 Debian doesn't play nicely with Xen.  That means that if I turn on
 SELinux on the kernel command line on my development machine, it
 crashes.  So it's not that easy for me to to SELinux-related testing.
  What I'm saying really is that I will apply bugfixes and try to
 resolve issues, but there may well be cases where I just can't
 reproduce problems.

I've conducted some testing on Debian and it behaves a bit weird. I am not 
sure yet, if the find is broken, or my Debian installation itself:

# uname -a
Linux debian 2.6.26-2-amd64 #1 SMP Sun Jun 21 04:47:08 UTC 2009 x86_64 
GNU/Linux

# (cd find  find -maxdepth 1 -printf %p %Z\n)
. user_u:object_r:user_home_t:s0
./.cvsignore user_u:object_r:user_home_t:s0
./fstype.o unconfined_u:object_r:user_home_t:s0
...

# find find -maxdepth 1 -printf %p %Z\n
find user_u:object_r:user_home_t:s0
find/.cvsignore user_u:object_r:user_home_t:s0 
find/fstype.o find: getfilecon: `find/fstype.o': No such file or directory

find/finddata.o find: getfilecon: `find/finddata.o': No such file or directory

...

As time permits I will keep on trying to zero in this.

Kamil

Re: [PATCH 1/2] find: add SELinux support

[Kamil Dudka]

Hello,

On Mon July 13 2009 17:48:15 Kamil Dudka wrote:
 As time permits I will keep on trying to zero in this.

attached are strace outputs from Fedora and Debian. I can see one suspicious 
place in that - this is the first main difference between Fedora and Debian:

Fedora strace:
open(m4, O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
fcntl(5, F_GETFD)   = 0x1 (flags FD_CLOEXEC)
fchdir(5)   = 0
getdents(5, /* 14 entries */, 32768)= 456
getdents(5, /* 0 entries */, 32768) = 0
close(5)= 0

Debian strace:
open(m4, O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
fcntl(5, F_GETFD)   = 0x1 (flags FD_CLOEXEC)
fchdir(5)   = 0
getdents(5, /* 14 entries */, 32768)= 456
getdents(5, /* 0 entries */, 32768) = 0
close(5)= 0

In other words on Debian find does not change the working directory before 
calling lgetxattr syscall. That's why lgetxattr does not see the file and 
returns ENOENT (No such file or directory).

Does anybody here guess what's going on? (before I investigate it further)

Kamil

execve(/usr/local/bin/find, [find, m4, -printf, %Z\\n], [/* 17 vars 
*/]) = 0
brk(0)  = 0xe52000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fb7e04a3000
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fb7e04a1000
access(/etc/ld.so.preload, R_OK)  = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY)  = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=61363, ...}) = 0
mmap(NULL, 61363, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb7e0492000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/librt.so.1, O_RDONLY)   = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0p!\0\0\0\0\0\0@..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=31656, ...}) = 0
mmap(NULL, 2128848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7fb7e008
mprotect(0x7fb7e0087000, 2093056, PROT_NONE) = 0
mmap(0x7fb7e0286000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7fb7e0286000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/libm.so.6, O_RDONLY)= 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0P\0\0\0\0\0\0@..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=534736, ...}) = 0
mmap(NULL, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7fb7dfdfd000
mprotect(0x7fb7dfe7f000, 2093056, PROT_NONE) = 0
mmap(0x7fb7e007e000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x81000) = 0x7fb7e007e000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/libselinux.so.1, O_RDONLY)  = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\240]\0\0\0\0\0\0@..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=113672, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fb7e0491000
mmap(NULL, 2213648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7fb7dfbe
mprotect(0x7fb7dfbfb000, 2093056, PROT_NONE) = 0
mmap(0x7fb7dfdfa000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a000) = 0x7fb7dfdfa000
mmap(0x7fb7dfdfc000, 1808, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fb7dfdfc000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/libc.so.6, O_RDONLY)= 3
read(3, 
\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\300\346\1\0\0\0\0\0@..., 832) 
= 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1375536, ...}) = 0
mmap(NULL, 3482264, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7fb7df88d000
mprotect(0x7fb7df9d6000, 2097152, PROT_NONE) = 0
mmap(0x7fb7dfbd6000, 20480, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x149000) = 0x7fb7dfbd6000
mmap(0x7fb7dfbdb000, 17048, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fb7dfbdb000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/libpthread.so.0, O_RDONLY)  = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\300W\0\0\0\0\0\0@..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=125836, ...}) = 0
mmap(NULL, 2204512, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7fb7df672000
mprotect(0x7fb7df688000, 2093056, PROT_NONE) = 0
mmap(0x7fb7df887000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000

Re: [PATCH 1/2] find: add SELinux support

[Kamil Dudka]

On Tue July 14 2009 14:02:36 Kamil Dudka wrote:
 attached are strace outputs from Fedora and Debian. I can see one
 suspicious place in that - this is the first main difference between Fedora
 and Debian:

Oops, once again:

Fedora strace:
open(m4, O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
fcntl(5, F_GETFD)   = 0x1 (flags FD_CLOEXEC)
fchdir(5)   = 0
getdents(5, /* 14 entries */, 32768)= 456
getdents(5, /* 0 entries */, 32768) = 0
close(5)= 0

Debian strace:
openat(AT_FDCWD, m4, O_RDONLY)= 4
fstat(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fcntl(4, F_GETFL)   = 0x8000 (flags O_RDONLY|
O_LARGEFILE)
fcntl(4, F_SETFD, FD_CLOEXEC)   = 0
fcntl(4, F_DUPFD, 3)= 5
getdents(4, /* 14 entries */, 4096) = 456
getdents(4, /* 0 entries */, 4096)  = 0
close(4)= 0

 In other words on Debian find does not change the working directory before
 calling lgetxattr syscall. That's why lgetxattr does not see the file and
 returns ENOENT (No such file or directory).

 Does anybody here guess what's going on? (before I investigate it further)

Kamil

Re: [PATCH 1/2] find: add SELinux support

[Kamil Dudka]

On Tue July 14 2009 21:31:22 Eric Blake wrote:
 Kamil Dudka kdudka at redhat.com writes:
  In other words on Debian find does not change the working directory
  before calling lgetxattr syscall. That's why lgetxattr does not see the
  file and returns ENOENT (No such file or directory).

 One thing to look at would be kernel versions; not all kernels support
 openat and friends, so on older kernels, the fts traversal algorithms have
 to fake openat by using chdir, but on newer kernels, there are no chdir. 
 Meanwhile, it may be worth begging the kernel and glibc folks to consider
 implementing lgetxattrat and friends.

Sorry for confusion. My previous testing was completely wrong because I ran 
older version of findutils on Fedora. With the current git version it fails
on Fedora, too. It means something has been changed within findutils and/or 
gnulib in the meantime.

The attached incremental patch fixes it. Now it works on both Fedora and 
Debian. But unfortunately it does not work with the stable version (4.4.2)
of findutils. Could anybody point me to the relevant change in findutils
code? Thanks in advance!

Kamil


diff --git a/find/pred.c b/find/pred.c
index 77c2aac..ffc239b 100644
--- a/find/pred.c
+++ b/find/pred.c
@@ -1061,7 +1061,7 @@ do_fprintf(struct format_val *dest,
 	case 'Z':   /* SELinux security context */
 	  {
 	security_context_t scontext;
-	int rv = (*options.x_getfilecon) (state.rel_pathname, scontext);
+	int rv = (*options.x_getfilecon) (pathname, scontext);
 	if (rv  0)
 	  {
 		/* If getfilecon fails, there will in the general case
@@ -1899,7 +1899,7 @@ pred_context (const char *pathname, struct stat *stat_buf,
 	  struct predicate *pred_ptr)
 {
   security_context_t scontext;
-  int rv = (*options.x_getfilecon) (state.rel_pathname, scontext);
+  int rv = (*options.x_getfilecon) (pathname, scontext);
   if (rv  0)
 {
   error (0, errno, getfilecon: %s, safely_quote_err_filename (0, pathname));

Re: [PATCH 1/2] find: add SELinux support

[Kamil Dudka]

On Mon July 20 2009 13:33:23 Kamil Dudka wrote:
 Sorry for confusion. My previous testing was completely wrong because I ran
 older version of findutils on Fedora. With the current git version it fails
 on Fedora, too. It means something has been changed within findutils and/or
 gnulib in the meantime.

 The attached incremental patch fixes it. Now it works on both Fedora and
 Debian. But unfortunately it does not work with the stable version (4.4.2)
 of findutils. Could anybody point me to the relevant change in findutils
 code? Thanks in advance!

This seems to be the relevant change:

http://git.savannah.gnu.org/gitweb/?p=findutils.git;a=commitdiff;h=214320ca225da9c3f85c35fddd59c07045d6a6ff

Kamil

Re: [PATCH 1/2] find: add SELinux support

[Kamil Dudka]

On Thu August 6 2009 12:36:06 Kamil Dudka wrote:
 On Thu August 6 2009 12:16:58 Jim Meyering wrote:
  Kamil Dudka wrote:
   On Thu July 30 2009 13:57:00 Jim Meyering wrote:
The attached incremental patch fixes it. Now it works on both Fedora
and Debian. But unfortunately it does not work with the stable
version (4.4.2) of findutils. Could anybody point me to the relevant
change in findutils code? Thanks in advance!
  
   With the FTS_CWDFD-adding change you spotted,
   I suspect that you should be using an FD-based function,
   like getfileconat or lgetfileconat from coreutils.
  
   It's probably always better to use a FD-based function when working
   with an opened file. However this is not the case I think. Only FD of
   the traversed directory is available when getfilecon() is called. If I
   want to use FD of an opened  file, I need to open the file first. Then
   I am obviously encountering the same problem with relative paths.
 
  With FTS_CWDFD, the working directory does not change.
  Instead, fts-fts_cwd_fd is what changes.
  You can use getfileconat (fts-fts_cwd_fd, relative_name, context) to
  get the desired context.

 Thanks for the explanation! But the module selinux-at does not seem to be
 in gnulib. How can I then use it within findutils? I guess it's not good
 idea to copy the code to findutils repo...

I can see it's heavily based on modules openat and selinux-h which are 
available in gnulib. Anyway what's the reason why the selinux-at module is
not included in gnulib? Would by possible to move it from coreutils to gnulib?

Kamil

Re: [PATCH 1/2] find: add SELinux support

[Kamil Dudka]

On Thu August 6 2009 13:23:38 Jim Meyering wrote:
 Kamil Dudka wrote:
  On Thu August 6 2009 12:16:58 Jim Meyering wrote:
  Kamil Dudka wrote:
   On Thu July 30 2009 13:57:00 Jim Meyering wrote:
The attached incremental patch fixes it. Now it works on both
Fedora and Debian. But unfortunately it does not work with the
stable version (4.4.2) of findutils. Could anybody point me to the
relevant change in findutils code? Thanks in advance!
  
   With the FTS_CWDFD-adding change you spotted,
   I suspect that you should be using an FD-based function,
   like getfileconat or lgetfileconat from coreutils.
  
   It's probably always better to use a FD-based function when working
   with an opened file. However this is not the case I think. Only FD of
   the traversed directory is available when getfilecon() is called. If I
   want to use FD of an opened  file, I need to open the file first. Then
   I am obviously encountering the same problem with relative paths.
 
  With FTS_CWDFD, the working directory does not change.
  Instead, fts-fts_cwd_fd is what changes.
  You can use getfileconat (fts-fts_cwd_fd, relative_name, context) to
  get the desired context.
 
  Thanks for the explanation! But the module selinux-at does not seem to be
  in gnulib. How can I then use it within findutils? I guess it's not good
  idea to copy the code to findutils repo...

 I'll move them to gnulib.

Thanks!

Just let me note there is no explicit dependency on the openat module (namely 
lib/at-func.c). Is the dependency implied somehow?

Kamil

Re: [PATCH 1/2] find: add SELinux support

[Kamil Dudka]

On Thursday 06 of August 2009 14:01:37 Jim Meyering wrote:
 ...

  I'll move them to gnulib.
 
  Thanks!
 
  Just let me note there is no explicit dependency on the openat module
  (namely lib/at-func.c). Is the dependency implied somehow?

 Good point.
 I'll add that module dependency.  Thanks.

 I'll also do a stand-alone test, which should
 expose any other missing dependencies.

Thanks for the quick response. An incremental patch is attached for review.
I'll merge it with the original patch if the change is ok.

Kamil
diff --git a/find/defs.h b/find/defs.h
index c834baa..481c013 100644
--- a/find/defs.h
+++ b/find/defs.h
@@ -613,7 +613,7 @@ struct options
   int regex_options;
 
   /* function used to get file context */
-  int (*x_getfilecon) ();
+  int (*x_getfilecon) (int, const char *, security_context_t *);
 
   /* Optimisation level.  One is the default.
*/
diff --git a/find/parser.c b/find/parser.c
index c8b847f..330eb38 100644
--- a/find/parser.c
+++ b/find/parser.c
@@ -53,7 +53,7 @@
 #include unistd.h
 #include sys/stat.h
 
-#include selinux/selinux.h
+#include selinux-at.h
 
 #if ENABLE_NLS
 # include libintl.h
@@ -352,7 +352,8 @@ static const char *first_nonoption_arg = NULL;
 static const struct parser_table *noop = NULL;
 
 static int
-fallback_getfilecon (const char *name, security_context_t *p, int prev_rv)
+fallback_getfilecon (int fd, const char *name, security_context_t *p,
+		 int prev_rv)
 {
   /* Our original getfilecon () call failed.  Perhaps we can't follow a
* symbolic link.  If that might be the problem, lgetfilecon () the link.
@@ -365,7 +366,7 @@ fallback_getfilecon (const char *name, security_context_t *p, int prev_rv)
 	fprintf (stderr, fallback_getfilecon(): getfilecon(%s) failed; falling 
 			back on lgetfilecon()\n, name);
 #endif
-	return lgetfilecon (name, p);
+	return lgetfileconat (fd, name, p);
 
   case EACCES:
   case EIO:
@@ -389,23 +390,23 @@ fallback_getfilecon (const char *name, security_context_t *p, int prev_rv)
  * If the item to be examined is not a command-line argument, we
  * examine the link itself. */
 int
-optionh_getfilecon (const char *name, security_context_t *p)
+optionh_getfilecon (int fd, const char *name, security_context_t *p)
 {
   int rv;
   if (0 == state.curdepth)
 {
   /* This file is from the command line; dereference the link (if it is
 	 a link). */
-  rv = getfilecon (name, p);
+  rv = getfileconat (fd, name, p);
   if (0 == rv)
 	return 0;   /* success */
   else
-	return fallback_getfilecon (name, p, rv);
+	return fallback_getfilecon (fd, name, p, rv);
 }
   else
 {
   /* Not a file on the command line; do not dereference the link. */
-  return lgetfilecon (name, p);
+  return lgetfileconat (fd, name, p);
 }
 }
 
@@ -413,22 +414,22 @@ optionh_getfilecon (const char *name, security_context_t *p)
  * -L option is in effect.  That option makes us examine the thing the
  * symbolic link points to, not the symbolic link itself. */
 int
-optionl_getfilecon (const char *name, security_context_t *p)
+optionl_getfilecon (int fd, const char *name, security_context_t *p)
 {
-  int rv = getfilecon (name, p);
+  int rv = getfileconat (fd, name, p);
   if (0 == rv)
 return 0;  /* normal case. */
   else
-return fallback_getfilecon (name, p, rv);
+return fallback_getfilecon (fd, name, p, rv);
 }
 
 /* optionp_getfilecon () implements the stat operation when the -P
  * option is in effect (this is also the default).  That option makes
  * us examine the symbolic link itself, not the thing it points to. */
 int
-optionp_getfilecon (const char *name, security_context_t *p)
+optionp_getfilecon (int fd, const char *name, security_context_t *p)
 {
-  return lgetfilecon (name, p);
+  return lgetfileconat (fd, name, p);
 }
 
 void
@@ -2706,7 +2707,7 @@ parse_context (const struct parser_table* entry, char **argv, int *arg_ptr)
   error (1, 0, _(invalid predicate -context: SELinux is not enabled.));
   return false;
 }
-  our_pred = insert_primary (entry);
+  our_pred = insert_primary (entry, NULL);
   our_pred-est_success_rate = 0.01f;
   our_pred-need_stat = false;
 #ifdef DEBUG
diff --git a/find/pred.c b/find/pred.c
index 77c2aac..5c47290 100644
--- a/find/pred.c
+++ b/find/pred.c
@@ -1061,7 +1061,8 @@ do_fprintf(struct format_val *dest,
 	case 'Z':   /* SELinux security context */
 	  {
 	security_context_t scontext;
-	int rv = (*options.x_getfilecon) (state.rel_pathname, scontext);
+	int rv = (*options.x_getfilecon) (state.cwd_dir_fd, state.rel_pathname,
+	  scontext);
 	if (rv  0)
 	  {
 		/* If getfilecon fails, there will in the general case
@@ -1899,7 +1900,8 @@ pred_context (const char *pathname, struct stat *stat_buf,
 	  struct predicate *pred_ptr)
 {
   security_context_t scontext;
-  int rv = (*options.x_getfilecon) (state.rel_pathname, scontext);
+  int rv = 

Re: [PATCH 1/2] find: add SELinux support

[Kamil Dudka]

On Thu August 6 2009 18:15:28 Jim Meyering wrote:
 Kamil Dudka wrote:
  Thanks for the quick response. An incremental patch is attached for
  review. I'll merge it with the original patch if the change is ok.

 I glanced through quickly, and didn't see anything fishy.

Thanks for the review! I am attaching the merged patch. Note that the James' 
patch [1] is not included and should be applied on top of this one.

Kamil

[1] http://lists.gnu.org/archive/html/bug-findutils/2009-07/msg00041.html

From 0aaef3e5d4e72fb6944343f3611d6947a8fb42b6 Mon Sep 17 00:00:00 2001
From: Kamil Dudka kdu...@redhat.com
Date: Tue, 11 Aug 2009 16:47:29 +0200
Subject: [PATCH] find: add SELinux support

* find/defs.h: Add SELinux related definitions.
* find/tree.c: Add -context predicate to lookup.
* find/pred.c: Handle %Z printf directive.
* find/parser.c: Parse -context predicate and %Z printf directive.
* find/find.1: Mention -context predicate and %Z printf directive.
* doc/find.texi: Mention -context predicate and %Z printf directive.
* find/Makefile.am: Add SELinux libraries.
* import-gnulib.config: Require module selinux-at and the corresponding
version of gnulib.

Signed-off-by: Kamil Dudka kdu...@redhat.com
---
 ChangeLog|   13 +
 NEWS |4 ++
 doc/find.texi|   17 +++
 find/Makefile.am |2 +-
 find/defs.h  |6 ++
 find/find.1  |4 ++
 find/parser.c|  125 -
 find/pred.c  |   40 
 find/tree.c  |2 +
 import-gnulib.config |3 +-
 10 files changed, 211 insertions(+), 5 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 9c3290a..b4b956e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,16 @@
+2009-08-11  Kamil Dudka  kdu...@redhat.com
+
+	find: add SELinux support
+	* find/defs.h: Add SELinux related definitions.
+	* find/tree.c: Add -context predicate to lookup.
+	* find/pred.c: Handle %Z printf directive.
+	* find/parser.c: Parse -context predicate and %Z printf directive.
+	* find/find.1: Mention -context predicate and %Z printf directive.
+	* doc/find.texi: Mention -context predicate and %Z printf directive.
+	* find/Makefile.am: Add SELinux libraries.
+	* import-gnulib.config: Require module selinux-at and the corresponding
+	version of gnulib.
+
 2009-07-18  James Youngman  j...@gnu.org
 
 	Fix up some problems introduced in a manual conflict resolution.
diff --git a/NEWS b/NEWS
index 314022b..194ae33 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,10 @@ GNU findutils NEWS - User visible changes.	-*- outline -*- (allout)
 
 * Major changes in release 4.5.6-git, -MM-DD
 
+** Functional Enhancements to find
+
+patch #4848: Patch - Support for SELinux
+
 ** Bug Fixes
 
 #27017: find -D opt / -fstype ext3 -print , -quit coredumps.
diff --git a/doc/find.texi b/doc/find.texi
index 24ee8a8..1d6603e 100644
--- a/doc/find.texi
+++ b/doc/find.texi
@@ -1256,6 +1256,14 @@ situation.
 
 @end deffn
 
+...@deffn Test -context pattern
+True if file's SELinux context matches the pattern @var{pattern}.
+The pattern uses shell glob matching.
+
+This predicate is supported only on @code{find} versions compiled with
+SELinux support and only when SELinux is enabled.
+...@end deffn
+
 @node Contents
 @section Contents
 
@@ -1747,6 +1755,7 @@ from the novel you are reading.
 * Size Directives::
 * Location Directives::
 * Time Directives::
+* Other Directives::
 * Formatting Flags::
 @end menu
 
@@ -1904,6 +1913,14 @@ File's last modification time in the format specified by @var{k}
 (@pxref{Time Formats}).
 @end table
 
+...@node Other Directives
+...@subsubsection Other Directives
+
+...@table @code
+...@item %Z
+File's SELinux context, or empty string if the file has no SELinux context.
+...@end table
+
 @node Time Formats
 @subsection Time Formats
 
diff --git a/find/Makefile.am b/find/Makefile.am
index 91dba85..c0a4164 100644
--- a/find/Makefile.am
+++ b/find/Makefile.am
@@ -27,7 +27,7 @@ endif
 
 EXTRA_DIST = defs.h sharefile.h $(man_MANS)
 INCLUDES = -I../gnulib/lib -I$(top_srcdir)/lib -I$(top_srcdir)/gnulib/lib -I../intl -DLOCALEDIR=\$(localedir)\
-LDADD = ./libfindtools.a ../lib/libfind.a ../gnulib/lib/libgnulib.a $(LIBINTL) $(LIB_CLOCK_GETTIME) $(LIB_CLOSE) @FINDLIBS@
+LDADD = ./libfindtools.a ../lib/libfind.a ../gnulib/lib/libgnulib.a $(LIBINTL) $(LIB_CLOCK_GETTIME) $(LIB_CLOSE) @FINDLIBS@ @LIB_SELINUX@
 man_MANS = find.1
 SUBDIRS = . testsuite
 
diff --git a/find/defs.h b/find/defs.h
index 155927f..481c013 100644
--- a/find/defs.h
+++ b/find/defs.h
@@ -48,6 +48,7 @@ Please stop compiling the program now
 #include stdbool.h		/* for bool/boolean */
 #include stdint.h		/* for uintmax_t */
 #include sys/stat.h /* S_ISUID etc. */
+#include selinux/selinux.h
 
 
 
@@ -319,6 +320,7 @@ struct predicate
 struct samefile_file_id samefileid; /* samefile */
 mode_t type;		/* type */
 struct format_val printf_vec; /* printf fprintf fprint ls fls print0 fprint0 print

[PATCH] fts: do not fail on a submount during traversal

[Kamil Dudka]

Hello,

we've discussed with Jim the issue with mounts triggered during directory
tree traversal and we've decided to make a trade-off for now - enable the 
extra stat call only if the FTS_TIGHT_CYCLE_CHECK is set. This means it only 
affects find and du for now and leaves other utilities to work as they used
to work before (failing on the triggered mount). I think this is a good
enough temporary solution since we are still waiting for reply from the
kernel guys.

As for the indentation, I've attempted to do my best. Indentation of the 
fts_build() has been already broken completely. So please don't shout at me
I screwed it up :-)

Kamil
From 239d400abe783ad297b547e4e5a281cc1613ef70 Mon Sep 17 00:00:00 2001
From: Kamil Dudka kdu...@redhat.com
Date: Tue, 10 Nov 2009 14:26:56 +0100
Subject: [PATCH] fts: do not fail on a submount during traversal

* lib/fts.c (fts_build): Read the stat info again after opening
a directory if the FTS_TIGHT_CYCLE_CHECK flag is set.
Original report at http://bugzilla.redhat.com/501848.
---
 ChangeLog |7 +++
 lib/fts.c |   14 ++
 2 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 599a2ab..2ecd268 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2009-11-10  Kamil Dudka  kdu...@redhat.com
+
+	fts: do not fail on a submount during traversal
+	* lib/fts.c (fts_build): Read the stat info again after opening
+	a directory if the FTS_TIGHT_CYCLE_CHECK flag is set.
+	Original report at http://bugzilla.redhat.com/501848.
+
 2009-11-09  Eric Blake  e...@byu.net
 
 	rename: detect FreeBSD bug
diff --git a/lib/fts.c b/lib/fts.c
index 40a837e..6720946 100644
--- a/lib/fts.c
+++ b/lib/fts.c
@@ -1268,6 +1268,20 @@ fts_build (register FTS *sp, int type)
 	  opening it.  */
if (cur-fts_info == FTS_NSOK)
 	 cur-fts_info = fts_stat(sp, cur, false);
+   else if (sp-fts_options  FTS_TIGHT_CYCLE_CHECK) {
+		/* Now read the stat info again after opening a directory to
+		 * reveal eventual changes caused by a submount triggered by
+		 * the traverse.  But do it only for utilities which use
+		 * FTS_TIGHT_CYCLE_CHECK.  Therefore only find and du can
+		 * benefit from this feature for now.
+		 */
+		LEAVE_DIR (sp, cur, 4);
+		fts_stat (sp, cur, false);
+		if (! enter_dir (sp, cur)) {
+			 __set_errno (ENOMEM);
+			 return NULL;
+		}
+	}
 
 	/*
 	 * Nlinks is the number of possible entries of type directory in the
-- 
1.6.2.5

Re: [PATCH] fts: do not fail on a submount during traversal

[Kamil Dudka]

Hi Jim,

On Thu November 12 2009 12:44:48 Jim Meyering wrote:
 I've applied and pushed that.

thanks for considering it!

 I adjusted the comment, since I view this addition not as a feature,
 but rather as a kludge to work around brokenness in the NFS4
  implementation. Even though it affects only du and find now, the fact that
  everyone incurs a performance penalty for the work-around is irksome.

Sounds reasonably. Once we get the change into kernel, we'll change the FTS 
code accordingly.

Kamil

[bug #29089] SELinux --context and %Z options

[Kamil Dudka]

Follow-up Comment #1, bug #29089 (project findutils):

The bug is already filled at:

https://savannah.gnu.org/patch/?4848

Latest git patches available at:

http://lists.gnu.org/archive/html/bug-findutils/2009-11/msg00033.html

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?29089

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #29435] fd_is_cloexec () does not work on Fedora buildhosts

[Kamil Dudka]

Follow-up Comment #3, bug #29435 (project findutils):

Great!

built for Fedora as findutils-4.5.7-3.fc14

http://koji.fedoraproject.org/koji/buildinfo?buildID=165369

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?29435

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

assertion failures of findutils 4.5.7

[Kamil Dudka]

Hello,

Sami Farin (CC'd) discovered some flaws in recent findutils and reported
them at Red Hat bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=579476#c0
https://bugzilla.redhat.com/show_bug.cgi?id=579476#c2

Here are proposed patches:
https://bugzilla.redhat.com/attachment.cgi?id=404487
https://bugzilla.redhat.com/attachment.cgi?id=404490

Kamil

Re: assertion failures of findutils 4.5.7

[Kamil Dudka]

On Monday 05 of April 2010 22:01:22 James Youngman wrote:
 I attach a set of patches.  They're the same as the patches I emailed
 yesterday, but rebased against current head.

The patches look good!

I've applied all of them and built as findutils-4.5.7-4.fc14.  Thanks!

Kamil

[PATCH] fix bugs in run_in_dir ()

[Kamil Dudka]

Hello,

attached is a patch fixing bugs of run_in_dir () which I encountered while 
doing backport of #19593 for stable findutils.  Thanks in advance for 
considering the patch!

Kamil
diff --git a/lib/dircallback.c b/lib/dircallback.c
index 8497bee..ed36ee2 100644
--- a/lib/dircallback.c
+++ b/lib/dircallback.c
@@ -37,7 +37,7 @@ int
 run_in_dir (const struct saved_cwd *there,
 	int (*callback)(void*), void *usercontext)
 {
-  int err, saved_errno;
+  int err = -1, saved_errno;
   struct saved_cwd here;
   if (0 == save_cwd (here))
 {
@@ -50,6 +50,10 @@ run_in_dir (const struct saved_cwd *there,
 	{
 	  openat_restore_fail (errno);
 	}
+
+  if (restore_cwd (here) != 0)
+	openat_restore_fail (errno);
+
   free_cwd (here);
 }
   else

Re: [PATCH] fix bugs in run_in_dir ()

[Kamil Dudka]

On Thursday 06 of May 2010 15:03:32 Kamil Dudka wrote:
 Hello,

 attached is a patch fixing bugs of run_in_dir () which I encountered while
 doing backport of #19593 for stable findutils.  Thanks in advance for
 considering the patch!

Folow-up:

diff --git a/lib/dircallback.c b/lib/dircallback.c
index 9d77710..f96fccc 100644
--- a/lib/dircallback.c
+++ b/lib/dircallback.c
@@ -57,7 +57,8 @@ int
 run_in_dir (const struct saved_cwd *there,
int (*callback)(void*), void *usercontext)
 {
-  int err = -1, saved_errno;
+  int err = -1;
+  int saved_errno = 0;
   struct saved_cwd here;
   if (0 == save_cwd (here))
 {

 Kamil

Re: [PATCH] fix bugs in run_in_dir ()

[Kamil Dudka]

On Friday 07 of May 2010 10:41:03 James Youngman wrote:
 I have applied and pushed your patch as the two attached git patches
 (if you could send your changes in git format-patch format in
 future, ideally with a ChangeLog entry too, that would streamline
 things for me).

Sure, will do.

  https://bugzilla.redhat.com/493143

 Thanks for the pointer.   The semantics that Gen Zhang was relying on
 (processing all entries in a directory at once) were never guaranteed
 anyway.

The man page says:

As with the -exec action, the `+' form of -execdir will build a command
line to process more than one matched file, but any given invocation of
command  will only list files that exist in the same subdirectory.

And it didn't process more than one matched file, so I considered it as
bug, too.  Moreover the same used to work before the migration to fts.

 If you'd like to supply a backported format-patch patch against the
 4.4.x tree, I can apply that too.

It may sound stupid, but where can I get the upstream 4.4.x branch from?

The backport is currenlty pending our internal review, so that it makes
sense to hold on for a while.  I'll then provide the patches based on the 
upstream 4.4.x HEAD.

Kamil

Re: [PATCH] fix bugs in run_in_dir ()

[Kamil Dudka]

On Friday 07 of May 2010 10:56:52 Kamil Dudka wrote:
  If you'd like to supply a backported format-patch patch against the
  4.4.x tree, I can apply that too.

 It may sound stupid, but where can I get the upstream 4.4.x branch from?

Hopefully I got the right one:

$ git pull origin rel-4-4-fixes
From git://git.sv.gnu.org/findutils
 * branchrel-4-4-fixes - FETCH_HEAD

 Kamil

[bug #29949] find -execdr does not change working directory

[Kamil Dudka]

Additional Item Attachment, bug #29949 (project findutils):

File name: 0001-Fix-Savannah-bug-29949-execdir-does-not-change-worki.patch
Size:2 KB


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?29949

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[PATCH 1/3] Eliminate a misleading message of import-gnulib.sh

[Kamil Dudka]

... on a fresh repository obtained by 'git clone --recursive'.
* import-gnulib.sh (check_old_gnulib_dir_layout): Do not require
./gnulib/.git to be a directory.
---
 ChangeLog|7 +++
 import-gnulib.sh |2 +-
 2 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 5bdc656..c61da2e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2013-02-03  Kamil Dudka  kdu...@redhat.com
+
+   Eliminate a misleading message of import-gnulib.sh on a fresh
+   repository obtained by 'git clone --recursive'.
+   * import-gnulib.sh (check_old_gnulib_dir_layout): Do not require
+   ./gnulib/.git to be a directory.
+
 2013-02-03  James Youngman  j...@gnu.org
 
* po/findutils.pot: Updated template file from the Translation
diff --git a/import-gnulib.sh b/import-gnulib.sh
index 9912e09..073ddb0 100755
--- a/import-gnulib.sh
+++ b/import-gnulib.sh
@@ -346,7 +346,7 @@ EOF
# No ./gl/ and no ./gnulib-git/.   If ./gnulib/ exists, it might
# be either.   If there is no ./gnulib/ we are safe to proceed anyway.
if test -d ./gnulib/; then
-   if test -d ./gnulib/.git; then
+   if test -e ./gnulib/.git; then
# Looks like it is the submodule.
true
else
-- 
1.7.1

Re: [PATCH 3/3] Fix compile-time warnings.

[Kamil Dudka]

On Sunday 03 February 2013 23:07:42 Kamil Dudka wrote:
 diff --git a/find/exec.c b/find/exec.c
 index aa69fe3..f731d82 100644
 --- a/find/exec.c
 +++ b/find/exec.c
 @@ -324,7 +324,7 @@ launch (struct buildcmd_control *ctl, void
  *usercontext, int argc, char **argv) }
   }
 
 -  if (bc_args_exceed_testing_limit (argv))
 +  if (bc_args_exceed_testing_limit ((const char **) argv))
   errno = E2BIG;
else
   execvp (argv[0], argv);

As James pointed out, the above type-cast is insane because it might allow to 
assign a string literal to an item of an array of modifiable strings.  If we 
want the compiler to check that bc_args_exceed_testing_limit() accesses the 
array of strings in a read-only manner, its prototype should be:

bool bc_args_exceed_testing_limit (const char *const *argv);

The problem is that such a type definition is actually useful in C++ only.
For C compilers, we would need the explicit type-casts anyway.  Hence, I 
propose to remove the const modifier from the bc_args_exceed_testing_limit() 
prototype completely because the C language does not seem to support the
type-constraint we need.  Here are some resources on this topic:

http://c-faq.com/ansi/constmismatch.html

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49748

Does anyone have a better idea how to fix these warnings?

Kamil

[PATCH] Prevent 'make clean' from removing git-tracked files in lib/.

[Kamil Dudka]

* lib/Makefile.am (libfind_a_SOURCES): Move header files to EXTRA_DIST
in order not to get them on the CLEANFILES list due to unmatched string
substitutions.
---
 ChangeLog   |7 +++
 lib/Makefile.am |2 +-
 2 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index d96adc0..18e44f0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2013-02-04  Kamil Dudka  kdu...@redhat.com
+
+   Prevent 'make clean' from removing git-tracked files in lib/.
+   * lib/Makefile.am (libfind_a_SOURCES): Move header files to EXTRA_DIST
+   in order not to get them on the CLEANFILES list due to unmatched
+   string substitutions.
+
 2013-02-03  Kamil Dudka  kdu...@redhat.com
 
Fix compile-time warnings.
diff --git a/lib/Makefile.am b/lib/Makefile.am
index eba43d2..a2c931f 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -31,7 +31,7 @@ MAINTAINERCLEANFILES =
 AM_CPPFLAGS = -I../gl/lib -I$(top_srcdir)/gl/lib
 LDADD = ../gl/lib/libgnulib.a $(LIBINTL)
 
-libfind_a_SOURCES += printquoted.h listfile.h \
+EXTRA_DIST += printquoted.h listfile.h \
regextype.h dircallback.h safe-atoi.h splitstring.h
 libfind_a_SOURCES += listfile.c extendbuf.c buildcmd.c \
forcefindlib.c qmark.c printquoted.c regextype.c dircallback.c fdleak.c 
\
-- 
1.7.1

Re: [PATCH] Prevent 'make clean' from removing git-tracked files in lib/.

[Kamil Dudka]

On Sunday, March 24, 2013 14:13:23 James Youngman wrote:
 Thanks for the patch.  However, since we used the same idiom elsewhere
 in the code, I thought that a more extensive change was justified.   I
 committed the fix as
 http://git.savannah.gnu.org/cgit/findutils.git/commit/?id=a917eb988fab87e474
 55c73731941d6fbfd1cf69. The fix also cleans output files in directories
 where the
 Makefile.am file is generated by gnulib-tool, too.

I can confirm that 'make clean' now works as expected (although I did not 
check cleaning the coverage files).  Thanks for the fixup!

Kamil

Re: I need help to use find and curl together to upload a directory

[Kamil Dudka]

On Tuesday 13 August 2013 01:35:02 Christoph Roland Murauer wrote:
 Am 12.08.2013 um 18:46 schrieb James Youngman j...@gnu.org:
  I don't clearly understand the problem you are trying to describe (you
  might find it helpful to review
  http://www.catb.org/esr/faqs/smart-questions.html).   Are you saying
  that find launches curl with an incorrect command-line?If so, what
  command-line did you want and what are you getting?  If curl is being
  launched with the command-line you expect, but you are not getting the
  result you hope for, this is likely a problem that you should take up
  with the curl user mailing list and/or developers.
 
 I don't know which part is the problem (find, curl or me). Maybe I kept my
  question a littlebit to short.
 
  But since you are passing --ftp-create-dirs to curl, perhaps you don't
  want to pass any directories as the expansion of {} when invoking
  curl.   If that's the case you could just put -type f on find's
  command-line before the -exec.
 
 I have on the FTP a directory call images.
 
 I have the following local structure which I want to upload (_site, css,
  images and posts are directories).
 
 _site
 
 |- archive.html
 |- css
 |
 ||- default.css
 |
 |- images
 |. |- whatever.png
 |- index.html
 |- posts
 |
|- whatever.html
 
 After running (inside the _site directory)
 
 find . -exec curl --ftp-create-dirs -T {} -v -k -u user@name:password
  ftp://server/directory --ftp-ssl \;
 
  ... I had the following on the FTP.
 
 archive.html
 css
 default.css
 images
 whatever.png
 index.html
 posts
 whatever.html
 
 css and posts are created as empty files (like with touch) and not as
  directories like in the original structure. images is still a directory
  and untouched.
 
 Find should query the directory _site and forward the result to curl. Curl
  should upload everything and if it is a directory which doesn't exist on
  the FTP, then curl should creat it as a directory and not as a file.

It cannot work this way.  The -T option of curl takes only one argument.  You 
need to call curl with multiple pairs of local/remote locations.  Please have 
a look at the curl.1 man page.  You may also want to exclude the directories 
from the list of files being transferred as James suggested.

Kamil

Re: Announcing the release of GNU findutils 4.5.12

[Kamil Dudka]

Hi James,

would it be possible to create lightweight git tags for this release, as well 
as the release 4.5.11, in the upstream git repository?  Thanks in advance!

Kamil


On Sunday, September 22, 2013 22:45:12 James Youngman wrote:
 I am pleased to announce the release of version 4.5.12 of GNU
 findutils.
 
 GNU findutils is a set of software tools for finding files that match
 certain criteria and for performing various operations on them.
 Findutils includes the programs find, xargs and locate.  More
 information about findutils is available at
 http://www.gnu.org/software/findutils/.
 
 This is a development release of findutils.  It can be downloaded from
 ftp://alpha.gnu.org/gnu/findutils.  The 4.5.x release series is
 intended to allow people to try out, comment on or contribute to new
 features of findutils.  During the 4.5.x release series some features
 may be introduced and then changed or removed as a result of feedback
 or experience.  In short, please don't rely on backward compatibility
 later in the release series.
 
 While this is a development release, it is tested before being
 released, principally with the regression test suite (run make check
 to use it).  The Savannah website
 (http://savannah.gnu.org/bugs/?group=findutils) contains a current
 list of known bugs in findutils (for both the stable and development
 branches).
 
 Bugs in GNU findutils should be reported to the findutils bug tracker
 at http://savannah.gnu.org/bugs/?group=findutils.  Reporting bugs via
 the web interface will ensure that you are automatically informed when
 the bug has been fixed.  General discussion of findutils takes place
 on the bug-findutils mailing list.  To join the 'bug-findutils'
 mailing list, send email to bug-findutils-requ...@gnu.org.
 
 To verify the GPG signature of the release, you will need the public
 key of the findutils maintainer, James Youngman.  You can download
 this from http://savannah.gnu.org/users/jay.  Please note that the key
 being used is not the same as the key that was used to sign previous
 releases.
 
 I'd like to thank the following people for their contributions to this
 release:
 
 Andreas Metzler
 David Gilbert
 Bernhard Voelker
 Kamil Dudka
 Peter Breitenlohner
 Karl Berry
 Paul Eggert
 Benedikt Morbach
 Dmitry V. Levin
 Dan Jidanni Jacobson
 
 
 * Major changes in release 4.5.12, 2013-09-22
 
 ** Functional Changes to find
 
 The GNU extension find ... -perm /MODE is no longer disabled when
 the POSIXLY_CORRECT environment variable is set.
 
 The obsolete GNU extension find ... -perm +MODE, which was withdrawn
 in release 4.2.21 in 2005 due to compatibility problems, has been
 completely removed.  Use find ... -perm /MODE instead.
 
 ** Documentation Changes
 
 If you use -type or -xtype with a type letter corresponding to a file
 type which is not supported by the system on which find was compiled,
 find will now give a clearer error message (though the functionality
 is unchanged).  Type letters are affected are D, l and p (for Solaris
 Doors, symbolic links and named pipes respectively).
 
 The output of xargs --help has been slightly changed for greater
 clarity.
 
 The documentation for xargs now warns about parallel processes (xargs
 -P) sharing stdout.
 
 The documentation for find -execdir now describes correctly that the
 command will be executed in the same directory as the file we were
 considering at the time.  The documentation previously (and
 incorrectly) stated that the original working directory of find would
 be used.
 
 ** Bug Fixes
 
 Some bugs in 4.5.11 were fixed without adding them to the bug
 database, though they are in the ChangeLog:
 
 *** Use of [[ ... ]] in find/testsuite/sv-bug-32043.sh
 
 *** Don't delete header files in lib/ for make clean.
 
 *** xargs: wait for process before prompting in interactive mode (-p)
 
 These following fixed bugs are recorded at
 https://savannah.gnu.org/bugs/?group=findutils:
 
 #40088: potential buffer overflow in -execdir and -okdir
 
 #39324: exits without error on OOM
 
 #38583: errno-buffer read failed in xargs_do_exec
 
 #38474: Unintended (?) behaviour change of -perm +mode predicate
 
 #36652: Better document that -0/-d turns off the effect of -E.
 
 #34976: find -execdir leaks file descriptors for the working directory
 
 --
 James Youngman j...@gnu.org
 GNU findutils maintainer

[bug #44221] Spurious warning about non-option arguments is spurious

[Kamil Dudka]

Follow-up Comment #3, bug #44221 (project findutils):

That might be true in your simple case, but it does not hold in general.  What
about the following command for instance?

find -type f -ls -a -mindepth 4 -delete

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?44221

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #44221] Spurious warning about non-option arguments is spurious

[Kamil Dudka]

Follow-up Comment #1, bug #44221 (project findutils):

-mindepth and -maxdepth are options whereas -type is a test.  You need to
specify options before non-optionos (tests and actions).

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?44221

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[PATCH] clarify exit status handling of -exec command {} +

[Kamil Dudka]

* find(-exec): Explain how exit status is propagated if the
-exec command {} + syntax is used.

Reported at https://bugzilla.redhat.com/1325049
---
 find/find.1 | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/find/find.1 b/find/find.1
index c948b4b..2c228f8 100644
--- a/find/find.1
+++ b/find/find.1
@@ -1066,22 +1066,25 @@ option instead.
 .IP "\-exec \fIcommand\fR {} +"
 This variant of the
 .B \-exec
 action runs the specified command on the
 selected files, but the command line is built by appending each
 selected file name at the end; the total number of invocations of the
 command will be much less than the number of matched files.  The
 command line is built in much the same way that
 .B xargs
 builds its command lines.  Only one instance of `{}' is allowed within
 the command.  The command is executed in the starting directory.  If
+any invocation returns a non-zero value as exit status, the
+.B find
+utility returns a non-zero exit status.  If
 .B find
 encounters an error, this can sometimes cause an
 immediate exit, so some pending commands may not be run
 at all.  This variant of
 .B \-exec
 always returns true.
 
 .IP "\-execdir \fIcommand\fR ;"
 .IP "\-execdir \fIcommand\fR {} +"
 Like
 .BR \-exec ,
-- 
2.7.3

Re: [PATCH] clarify exit status handling of -exec command {} +

[Kamil Dudka]

On Sunday, April 17, 2016 22:46:22 Bernhard Voelker wrote:
> On 04/13/2016 03:07 PM, Kamil Dudka wrote:
> > * find(-exec): Explain how exit status is propagated if the
> > -exec command {} + syntax is used.
> > 
> > Reported at https://bugzilla.redhat.com/1325049
> 
> Thanks for the report and the patch.
> I thought this was already documented somewhere, but obviously not
> in the man page (probably in the Texinfo manual).
> 
> > ---
> > 
> >  find/find.1 | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/find/find.1 b/find/find.1
> > index c948b4b..2c228f8 100644
> > --- a/find/find.1
> > +++ b/find/find.1
> > @@ -1066,22 +1066,25 @@ option instead.
> > 
> >  .IP "\-exec \fIcommand\fR {} +"
> >  This variant of the
> >  .B \-exec
> >  action runs the specified command on the
> >  selected files, but the command line is built by appending each
> >  selected file name at the end; the total number of invocations of the
> >  command will be much less than the number of matched files.  The
> >  command line is built in much the same way that
> >  .B xargs
> >  builds its command lines.  Only one instance of `{}' is allowed within
> >  the command.  The command is executed in the starting directory.  If
> > 
> > +any invocation returns a non-zero value as exit status, the
> 
> s/the$/then/

Not a typo, the$ was intended but ... both wordings sound fine to me :-)

> > +.B find
> > +utility returns a non-zero exit status.  If
> > 
> >  .B find
> >  encounters an error, this can sometimes cause an
> >  immediate exit, so some pending commands may not be run
> >  at all.  This variant of
> >  .B \-exec
> >  always returns true.
> >  
> >  .IP "\-execdir \fIcommand\fR ;"
> >  .IP "\-execdir \fIcommand\fR {} +"
> >  Like
> >  .BR \-exec ,
> 
> The same applies to -execdir (which should be preferred anyway).
> I've added that in the attached, and adjusted the commit message
> to GNU standards.  I'll push that in your name soon.

Looks good to me.  Thank you for polishing the patch!

Kamil

> Thanks & have a nice day,
> Berny

Re: Fwd: help us to resolve this command

[Kamil Dudka]

On Friday, August 11, 2017 16:17:30 Aman ulla wrote:
> how can i run this command in our centos 7 server to get results..?

It depends on which results you want to get.  My suggestion is not to run 
commands as root unless you really understand what they do ;-)

> # find /root/home/ -mindepth 1 -type f -not -name '.*' -delete && find
> /root/home/ -type d -not \(\-name '.*' -or -name 'Desktop' -or -name
> 'thinclient_drives' \) -delete
> 
> this command gives this error.
> 
> find: paths must precede expression: (-name

The error message sounds clear to me.  You likely want to spell \(\-name
as \( -name so that ( ... ) is recognized as operator, instead of badly 
positioned path.

Note that the back slashes are consumed by your shell, not by find itself.

Kamil

> Usage: find [-H] [-L] [-P] [-Olevel] [-D
> help|tree|search|stat|rates|opt|exec] [path...] [expression]
> 
> kindly help us to resolve this..
> 
> 
> Thanks in Advance.
> 
> 
> 
> 
> 
> --
>  " Don't pollute it,good planets are hard to
> find "
> 
>  *-*-*   Unity is Strength   *-*-*
> 
> Regards,
> S.Amanulla

Re: [bug #51345] find shows different results despite using same command

[Kamil Dudka]

On Wednesday, July 05, 2017 16:01:53 James Youngman wrote:
> Follow-up Comment #4, bug #51345 (project findutils):
> 
> Try again, passing also the option -noleaf to find.

The -noleaf option of find is silently ignored if find is built with FTS.
I proposed a gnulib patch that would allow us to make the -noleaf option
work again but the patch has not been merged yet:

https://www.mail-archive.com/bug-gnulib@gnu.org/msg31905.html

Kamil

Re: Several changes made to fts.c in Gnulib

[Kamil Dudka]

On Tuesday, July 25, 2017 02:16:30 Paul Eggert wrote:
> I found some subtle bugs in Gnulib fts.c, and created a test case that
> reliably fails in reiserfs due to confusion with st_nlink. I added this
> test case to Gnulib and fixed the bugs I found. As far as I can see, the
> only problems that should affect findutils and coreutils are minor
> performance problems. However, I thought I'd send out some email as a
> heads-up, because the code is reasonably subtle and I may have introduced
> some bugs.

Any chance to make the (still documented) -noleaf option of find work again?

https://www.mail-archive.com/bug-gnulib@gnu.org/msg31905.html

Kamil

> Here are the patches I installed:
> 
> http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=b7363b496caf60600eefa
> 0a5f2d37f77a5dee606
> 
> http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=9c7ef4eef9540a0a762c4
> 781d7ed5a1b8623e59b
> 
> http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=f7eb1b99e30517fc50c13
> 0cdecec24059a1b7c4f
> 
> http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=2649851d0409c3fafee7c
> f396d11c10892ac0e53
> 
> http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=b446700e06b71f8170c46
> 371261e8334888df7f8
> 
> http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=e66b0b94e7239fb47c9cc
> c2c704bb1149164d6ed

Re: Several changes made to fts.c in Gnulib

[Kamil Dudka]

On Tuesday, July 25, 2017 09:10:09 Paul Eggert wrote:
> Kamil Dudka wrote:
> > Any chance to make the (still documented) -noleaf option of find work
> > again?
> I'm inclined to agree with Pádraig, in thinking that fts should Just Work
> without the complexity of an extra option to disable an optimization that is
> supposed to work.

With this reasoning, you could also deprecate gcc -O0 and the like because 
compiler optimizations should just work...

While I respect your opinion about removing this debugging facility upstream, 
the -noleaf option stays implemented in Fedora.  It has already helped me to 
quickly find the root cause of https://bugzilla.redhat.com/1299169 so I was 
able to report it to gnulib upstream and, based on that, Pádraig could revert 
the change that had been causing a serious regression in the upcoming release 
of coreutils.

There is no maintenance overhead with that already existing -noleaf option.  
Removing it would only complicate the life to users affected by this class
of bugs, support engineers, and file system developers.

Kamil

> As things stand, 'find' can disable leaf optimization by using a bigger
> hammer, namely, turn off FTS_CURDIR. However, my suggestion is to deprecate
> the -noleaf option while you're at it.

Re: Several changes made to fts.c in Gnulib

[Kamil Dudka]

On Wednesday, July 26, 2017 09:31:47 Paul Eggert wrote:
> Kamil Dudka wrote:
> > You even admitted that they could have introduced new bugs.  Now you are
> > refusing to push a tiny commit that would significantly help to debug them
> > in environments where only binaries are available.
> 
> My changes fixed some bugs and did not affect the fts API. Your changes
> would complicate the API, and this complexity is the principal objection.

The API complexity is increased exactly by one bit.  If it is such a big 
problem for upstream maintainers, I will continue to maintain this added 
complexity myself.  It has been maintained in Fedora since December 2015
with zero manpower spent on it so far.

Kamil

Re: Several changes made to fts.c in Gnulib

[Kamil Dudka]

On Friday, July 28, 2017 11:38:12 Paul Eggert wrote:
> The only thing I'd add to that is to suggest using a high value like
> 0x4000 for FTS_NOLEAF.

I am fine with my current patch.  If gnulib upstream introduces new flags 
later on, it will be not that difficult to find a free bit for FTS_NOLEAF.

Thank you all for replies!

Kamil

SIGSEGV in partial_quotearg_n()

[Kamil Dudka]

We have multiple occurrences of automated crash reports:

https://retrace.fedoraproject.org/faf/reports/1209278/

... about SIGSEGV in partial_quotearg_n() at this location in the source code:

http://git.savannah.gnu.org/cgit/findutils.git/tree/find/ftsfind.c?h=v4.6.0#n219

I guess it crashes because ent->fts_cycle->fts_pathlen is out of bound of
ent->fts_cycle->fts_path but I do not fully understand what the function
is supposed to do...

Kamil

Re: "find: '/usr/...': Too many open files" when using -execdir

[Kamil Dudka]

On Saturday, June 03, 2017 09:03:54 Dale R. Worley wrote:
> I know I've seen something about this before:  When I use -execdir, I
> get a message like:
> 
> find: '/usr/share/texlive/texmf-dist/tex4ht/ht-fonts/alias/kurier/sy-iwona':
> Too many open files find: Failed to save working directory in order to run
> a command on 'qx-iwonacap': Too many open files
> 
> But I can't find an entry in the bug tracker
> (http://savannah.gnu.org/bugs/?group=findutils) about it.  (BTW, the
> search facilities in that tracker are really poor.)

I believe it is fixed by the following upstream commit, which includes also 
indentation changes, unfortunately:

http://git.savannah.gnu.org/cgit/findutils.git/commit/?id=183115d0

Here you can find the actual fix extracted from the above commit:

https://bugzilla.redhat.com/1223557#c2

... and this seems to be the related upstream bug report:

https://savannah.gnu.org/bugs/?34976

Kamil

> It seems that replacing -execdir with -exec makes that problem go
> away, but as the manual page says, there are significant security
> problems with -exec.
> 
> Dale

[bug #51841] find buffer-overflow with -printf '%T+'

[Kamil Dudka]

Follow-up Comment #1, bug #51841 (project findutils):

I think that both the bug and the fix are obvious.  After the mentioned
patch,
the code writes 12 bytes into a stack-allocated array of size 6 bytes:

  char fmt[6];

  // [...]

  /* Format the main part of the time. */
  if (kind == '+')
{
  /* Avoid %F, some Unix versions lack it.  For example:
 HP Tru64 UNIX V5.1B (Rev. 2650); Wed Feb 17 22:59:59 CST 2016
 Also, some older HP-UX versions expand %F as the full month (like
%B).
 Reported by Steven M. Schweda  */
  strcpy (fmt, "%Y-%m-%d+%T");

I believe that increasing size of the fmt array to 12 bytes will fix the bug.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: SIGSEGV in partial_quotearg_n()

[Kamil Dudka]

On Monday, August 28, 2017 11:51:08 PM CEST Bernhard Voelker wrote:
> On 08/18/2017 04:23 PM, Kamil Dudka wrote:
> > We have multiple occurrences of automated crash reports:
> > 
> > https://retrace.fedoraproject.org/faf/reports/1209278/
> > 
> > ... about SIGSEGV in partial_quotearg_n() at this location in the source
> > code:
> > 
> > http://git.savannah.gnu.org/cgit/findutils.git/tree/find/ftsfind.c?h=v4.6.
> > 0#n219
> > 
> > I guess it crashes because ent->fts_cycle->fts_pathlen is out of bound of
> > ent->fts_cycle->fts_path but I do not fully understand what the function
> > is supposed to do...
> 
> The FAF page doesn't show much.  Any reproducer? Or at least the command
> line arguments, or ...?

Unfortunately not.  These reports are anonymous and they have to respect 
user's privacy.  I do not have any info except the FAF page I linked :-/

Kamil

> Thanks & have a nice day,
> Berny

Re: [PATCH] find: properly support -noleaf in ftsfind.

[Kamil Dudka]

On Saturday, September 2, 2017 5:35:31 PM CEST James Youngman wrote:
> * gnulib-local/lib/fts.c.diff: incorporated from a patch by Kamil
> Dudka <kdu...@redhat.com>.  This patch introduces an FTS_NOLEAF option
> to fts.
> * gnulib-local/lib/fts_.h.diff: Likewise.
> * find/ftsfind.c (ftsoptions): point out that is_fts_enabled
> reflects the settings made in the initialization of ftsoptions,
> not the modifications made later to it (e.g. FTS_NOLEAF).
> (find): Set fts_options |= FTS_NOLEAF when the -noleaf option was
> specified.  With -D search, the debugging output now shows the
> options passed to fts_open.
> (is_fts_enabled): Point out that the result doesn't reflect any
> dynamic changes to ftsoptions (e.g.  FTS_NOLEAF).
> * Makefile.am (EXTRA_DIST): Distribute fts.c.diff and fts_.h.diff in
> gnulib-local/lib.  These diffs will be applied to the gnulib sources
> by gnulib-tool (hence, the gnulib code shipped in the source tarball
> will already include these patches).
> * find/parser.c (parse_version): For the FTS feature, indicate
> whether FTS_NOLEAF is available (but not whether it was used; for
> that you have to use the command-line flag -D search).

Looks good.  Thank you for working on this!  I have verified on a reiserfs 
file system that it works as expected.  Please consider applying the following 
fixup to make the patch apply better on up2date gnulib code:

--- a/gnulib-local/lib/fts.c.diff
+++ b/gnulib-local/lib/fts.c.diff
@@ -10,14 +10,14 @@ diff --git a/lib/fts.c b/lib/fts.c
 index ea73675..76bbc06 100644
 --- a/lib/fts.c
 +++ b/lib/fts.c
-@@ -781,6 +781,10 @@ link_count_optimize_ok (FTSENT const *p)
-   bool opt_ok;
-   struct LCO_ent *t2;
+@@ -738,6 +738,10 @@ filesystem_type (FTSENT const *p)
+   struct dev_type *ent;
+   struct statfs fs_buf;

 +  if (ISSET(FTS_NOLEAF))
 +/* leaf optimization explicitly disabled by the FTS_NOLEAF flag */
-+return false;
++return 0;
 +
/* If we're not in CWDFD mode, don't bother with this optimization,
-  since the caller is not serious about performance. */
-   if (!ISSET(FTS_CWDFD))
+  since the caller is not serious about performance.  */
+   if (!ISSET (FTS_CWDFD))

Re: next release version of findutils?

[Kamil Dudka]

On Thursday, August 9, 2018 8:30:39 AM CEST Bernhard Voelker wrote:
> On 08/08/2018 09:49 AM, Karl Nordström wrote:
> > Hi,
> > 
> > I wanted to ask whether there is a new release for findutils comming up?
> > 
> > I want to add it to conda-forge and am having trouble passing make
> > check. Partly perhaps due to inexperience, but I think some of the tests
> > have been updated since 4.6.0. I think one such example is mbrtowc:
> > 
> > http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=1f63650823cebf52044
> > df840c81062ccb52163a2
> > 
> > The build system is very bare-bones and I'm also having problems with
> > strftime and the 'ahistorical' tests. Here I haven't delved as deep.
> > 
> > Currently I lean towards skipping the tests. Would you be terribly
> > opposed to that?
> > 
> > Best,
> > 
> > Karl
> 
> Hi Karl,
> 
> indeed, a new cut of the GNU findutils is overdue: we have already 187
> commits since v4.6.0 which was released around Xmas 2015.
> I have a few things open on my side, but then need to find some time to do
> the release together with James.
> 
> Re. the tests: in that situation, I'd try to skip the gnulib tests,
> and only let the find/xargs tests run.  Or you can try with a new snapshot
> tarball created with './bootstrap && ./configure && make all dist' from a
> git clone.

... or just pick the upstream commit(s) to make the test-suite pass again,
as we do in Fedora:

https://src.fedoraproject.org/cgit/rpms/findutils.git/commit?id=3f5b9b5d

Kamil

> Have a nice day,
> Berny

Re: next release version of findutils?

[Kamil Dudka]

On Thursday, August 9, 2018 5:09:51 PM CEST Karl Nordström wrote:
> Hi Kamil, hi Bernhard,
> 
> thank you for the response and your input.
> 
> I played around with the git clone yesterday when I tried to understand
> what went wrong. Conda has a bias towards release versions with static
> URLs though, but with the help of your inputs I think I'm quite close to
> something satisfactory.
> 
> In the end I borrowed most of the patches from Fedora (Is there a good
> way to reference/cite them?) and worked around the quirks of the build
> systems.

The cgit URLs that contain hash of the commit object in them are known to be
persistent, for example:

https://src.fedoraproject.org/cgit/rpms/findutils.git/tree/findutils-4.6.0-mbrtowc-tests.patch?id=97ba2d7a

(just replace findutils-4.6.0-mbrtowc-tests.patch in the URL by name of any
file that is currently in the master branch)

Kamil

> When the new version comes out I will update the conda recipe.
> 
> Again, thank you for your help.
> 
> Best,
> 
> Karl
> 
> On 09.08.2018 08:40, Kamil Dudka wrote:
> > On Thursday, August 9, 2018 8:30:39 AM CEST Bernhard Voelker wrote:
> >> On 08/08/2018 09:49 AM, Karl Nordström wrote:
> >>> Hi,
> >>> 
> >>> I wanted to ask whether there is a new release for findutils comming up?
> >>> 
> >>> I want to add it to conda-forge and am having trouble passing make
> >>> check. Partly perhaps due to inexperience, but I think some of the tests
> >>> have been updated since 4.6.0. I think one such example is mbrtowc:
> >>> 
> >>> http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=1f63650823cebf520
> >>> 44
> >>> df840c81062ccb52163a2
> >>> 
> >>> The build system is very bare-bones and I'm also having problems with
> >>> strftime and the 'ahistorical' tests. Here I haven't delved as deep.
> >>> 
> >>> Currently I lean towards skipping the tests. Would you be terribly
> >>> opposed to that?
> >>> 
> >>> Best,
> >>> 
> >>> Karl
> >> 
> >> Hi Karl,
> >> 
> >> indeed, a new cut of the GNU findutils is overdue: we have already 187
> >> commits since v4.6.0 which was released around Xmas 2015.
> >> I have a few things open on my side, but then need to find some time to
> >> do
> >> the release together with James.
> >> 
> >> Re. the tests: in that situation, I'd try to skip the gnulib tests,
> >> and only let the find/xargs tests run.  Or you can try with a new
> >> snapshot
> >> tarball created with './bootstrap && ./configure && make all dist' from a
> >> git clone.
> > 
> > ... or just pick the upstream commit(s) to make the test-suite pass again,
> > as we do in Fedora:
> > 
> > https://src.fedoraproject.org/cgit/rpms/findutils.git/commit?id=3f5b9b5d
> > 
> > Kamil
> > 
> >> Have a nice day,
> >> Berny

Re: [bug #54509] `-execdir command ;` returns 0 when it should not

[Kamil Dudka]

On Tuesday, August 14, 2018 10:43:44 PM CEST Bernhard Voelker wrote:
> Update of bug #54509 (project findutils):
> 
>   Status:None => In Progress
>  Assigned to:None => berny
> 
> ___
> 
> Follow-up Comment #1:
> 
> That sentence has recently been added to 'find.1', i.e., after the
> release of v4.6.0; references:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1325049
>   http://lists.gnu.org/archive/html/bug-findutils/2016-04/msg00014.html
>   https://git.sv.gnu.org/cgit/findutils.git/commit/?id=ae424b95
> 
> The problem is that it only applies to the '+' syntax, not to
> the ';' syntax of the -exec/-execdir/-ok/-okdir family.
> 
> The attached patch fixes the documentation.

Thanks for the patch!  I think the first hunk of your patch is unnecessary 
because the whole paragraph describes the '-exec command {} +' syntax only.  
The second hunk of your patch looks good and I believe it fixes this bug.

Kamil

[bug #54591] gnulib components in findutils do not compile with glibc 2.28

[Kamil Dudka]

Follow-up Comment #3, bug #54591 (project findutils):

... and the other error was fixed by
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=4af4a4a7

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re:

[Kamil Dudka]

On Sunday, July 22, 2018 10:09:49 PM CEST James Youngman wrote:
> On Thu, Jul 12, 2018 at 10:37 PM, Jonathan M. Wilbur
> 
>  wrote:
> > “find: ../../find/util.c:297: get_info: Assertion `p->st_ino' failed.”
> 
> Let's start by checking the symptom directly.   Assuming the problem
> is easily reproducible with a single file, please run the `stat`
> command on that file and show us the output.  You would do that like
> this:
> 
> $ stat README
>   File: README
>   Size: 4693  Blocks: 16 IO Block: 4096   regular file
> Device: fd04h/64772d Inode: 144515  Links: 1
> Access: (0644/-rw-r--r--)  Uid: ( 1027/   james)   Gid: ( 1027/   james)
> Access: 2018-07-06 09:41:30.650016507 +0100
> Modify: 2018-04-21 00:52:36.797927169 +0100
> Change: 2018-07-05 22:25:31.282307251 +0100
>  Birth: -
> 
> Here we see that this file is inode number 144515.   I'm wondering if
> the file you are having a problem with really appears (to stat(1)) to
> have st_ino==0, or not.
> 
> > I get this error when I run find on a mounted vboxsf filesystem.
> 
> I've not encountered these.   Could you provide - or point to -
> step-by-step instructions for reproducing your problem, please?
> 
> Thanks,
> James.

I am pretty sure this is caused by stat() returning st_ino==0.  There is
a (private) bug in Red Hat Bugzilla about find(1) crashing on the same 
assertion failure while traversing an Azure CIFS file system.  In that
case it was confirmed by strace that stat() returning st_ino==0 is the
actual cause of the crash.  However, I considered it to be rather a bug
in the file system implementation, not in the find(1) utility.

Kamil

Re: [PATCH 5/6] fts: three levels of leaf optimization

[Kamil Dudka]

On Tuesday, April 10, 2018 9:54:26 PM CEST Bernhard Voelker wrote:
> Hi Kamil,
> 
> On 04/06/2018 09:29 AM, Kamil Dudka wrote:
> > On Friday, April 6, 2018 8:08:55 AM CEST Bernhard Voelker wrote:
> >> On 04/05/2018 02:44 PM, Kamil Dudka wrote:
> >>> The same 'find' command with
> >>> the -noleaf option does not abort:
> >>> 
> >>> https://bugzilla.redhat.com/1558249#c20
> >> 
> >> This bug report is non-public.  Can you make it available, or
> >> post a reproducer, please?
> > 
> > I did not know it was private.  It should be publicly available now.
> 
> Thanks.
> 
> Although current upstream (v4.6.0-172-gb94be7a0) has already the
> non-CIFS-aware FTS change from gnulib, I couldn't reproduce the crash with
> a quick test here. I'll try again tomorrow.
> 
> Did you try with a build from upstream as well?
> 
> Thanks & have a nice day,
> Berny

I have not tried to reproduce the crash myself.  I was just analyzing the 
strace outputs attached to that bug.  I hope I will have some time next week 
to debug it deeper (in case nobody finds the cause till then).

Kamil

Re: [PATCH 5/6] fts: three levels of leaf optimization

[Kamil Dudka]

On Friday, April 6, 2018 8:08:55 AM CEST Bernhard Voelker wrote:
> CCing bug-findutils.
> original post https://lists.gnu.org/r/bug-gnulib/2018-04/msg00015.html
> 
> On 04/05/2018 02:44 PM, Kamil Dudka wrote:
> > We have a bug report where find aborts while traversing a CIFS file system
> > mounted on a directory on an XFS file system.
> 
> To the GNU findutils people:
> Redhat/Fedora had already the newer FTS/gnulib change in their product.
> That didn't make it into a newer release of upstream GNU findutils yet.

Yes, I have picked it to fix the following bug:

https://bugzilla.redhat.com/1544429

> > The same 'find' command with
> > the -noleaf option does not abort:
> > 
> > https://bugzilla.redhat.com/1558249#c20
> 
> This bug report is non-public.  Can you make it available, or
> post a reproducer, please?

I did not know it was private.  It should be publicly available now.

Kamil

> Have a nice day,
> Berny

[PATCH] find -samedev NAME: true for files on the same device as NAME

[Kamil Dudka]

There is no easy way to exclude mount points from the output of `find`.
The options -xdev or -mount prevent `find` from traversing over the
mount points but do not exclude the mount points themselves.  It could
be scripted by AWK on Linux as in the following example:

$ find / -xdev -maxdepth 1 $(awk '$2 != "/" { printf("! -path %s ", $2) }' 
/proc/mounts)

Would it make sense to introduce a new predicate similar to -samefile
that takes into account device numbers only?

With the proposed predicate implemented in `find`, the above command
could be encoded in a more user-friendly way:

$ find / -xdev -maxdepth 1 -samedev /

Originally reported at: https://bugzilla.redhat.com/1607772
---
 find/defs.h   |  1 +
 find/find.1   |  8 
 find/parser.c | 23 +++
 find/pred.c   | 18 ++
 find/tree.c   |  1 +
 5 files changed, 51 insertions(+)

diff --git a/find/defs.h b/find/defs.h
index 63f3b2a3..2d4965e9 100644
--- a/find/defs.h
+++ b/find/defs.h
@@ -461,6 +461,7 @@ PREDICATEFUNCTION pred_print0;
 PREDICATEFUNCTION pred_prune;
 PREDICATEFUNCTION pred_readable;
 PREDICATEFUNCTION pred_regex;
+PREDICATEFUNCTION pred_samedev;
 PREDICATEFUNCTION pred_samefile;
 PREDICATEFUNCTION pred_size;
 PREDICATEFUNCTION pred_true;
diff --git a/find/find.1 b/find/find.1
index 67fdd537..dec78798 100644
--- a/find/find.1
+++ b/find/find.1
@@ -932,6 +932,13 @@ newline), but this can be changed with the
 .B \-regextype
 option.
 
+.IP "\-samedev \fIname\fR"
+File is on the same device as
+.IR name .
+When
+.B \-L
+is in effect, this can include symbolic links.
+
 .IP "\-samefile \fIname\fR"
 File refers to the same inode as
 .IR name .
@@ -2282,6 +2289,7 @@ Feature   Added inAlso occurs in
 \-exec ... +   4.2.12  POSIX
 \-execdir  4.2.12  BSD
 \-okdir4.2.12
+\-samedev  4.6.1
 \-samefile 4.2.11
 \-H4.2.5   POSIX
 \-L4.2.5   POSIX
diff --git a/find/parser.c b/find/parser.c
index d6621506..14279c69 100644
--- a/find/parser.c
+++ b/find/parser.c
@@ -128,6 +128,7 @@ static bool parse_printf(const struct 
parser_table*, char *argv[], int *
 static bool parse_prune (const struct parser_table*, char *argv[], int 
*arg_ptr);
 static bool parse_regex (const struct parser_table*, char *argv[], int 
*arg_ptr);
 static bool parse_regextype (const struct parser_table*, char *argv[], int 
*arg_ptr);
+static bool parse_samedev   (const struct parser_table*, char *argv[], int 
*arg_ptr);
 static bool parse_samefile  (const struct parser_table*, char *argv[], int 
*arg_ptr);
 static bool parse_size  (const struct parser_table*, char *argv[], int 
*arg_ptr);
 static bool parse_time  (const struct parser_table*, char *argv[], int 
*arg_ptr);
@@ -290,6 +291,7 @@ static struct parser_table const parse_table[] =
   {ARG_TEST,   "readable",parse_accesscheck, pred_readable}, 
/* GNU, 4.3.0+ */
   PARSE_TEST   ("regex", regex),/* GNU */
   PARSE_POSOPT ("regextype", regextype), /* GNU */
+  PARSE_TEST   ("samedev",   samedev),  /* GNU */
   PARSE_TEST   ("samefile",  samefile), /* GNU */
 #if 0
   PARSE_OPTION ("show-control-chars",show_control_chars), /* GNU, 
4.3.0+ */
@@ -2169,6 +2171,27 @@ parse_size (const struct parser_table* entry, char 
**argv, int *arg_ptr)
 }
 
 
+static bool
+parse_samedev (const struct parser_table* entry, char **argv, int *arg_ptr)
+{
+  struct predicate *our_pred;
+  struct stat st;
+  const char *filename;
+
+  set_stat_placeholders ();
+  if (!collect_arg_stat_info (argv, arg_ptr, , ))
+return false;
+
+  our_pred = insert_primary (entry, filename);
+  our_pred->args.samefileid.ino = (ino_t) -1;
+  our_pred->args.samefileid.dev = st.st_dev;
+  our_pred->args.samefileid.fd  = -1;
+  our_pred->need_type = false;
+  our_pred->need_stat = true;
+  our_pred->est_success_rate = 1.0f;
+  return true;
+}
+
 static bool
 parse_samefile (const struct parser_table* entry, char **argv, int *arg_ptr)
 {
diff --git a/find/pred.c b/find/pred.c
index 2014b5ab..f1da8669 100644
--- a/find/pred.c
+++ b/find/pred.c
@@ -118,6 +118,7 @@ struct pred_assoc pred_table[] =
   {pred_quit, "quit"},
   {pred_readable, "readable"},
   {pred_regex, "regex   "},
+  {pred_samedev, "samedev  "},
   {pred_samefile,"samefile "},
   {pred_size, "size"},
   {pred_true, "true"},
@@ -986,6 +987,23 @@ pred_size (const char *pathname, struct stat *stat_buf, 
struct predicate *pred_p
   return (false);
 }
 
+bool
+pred_samedev (const char *pathname, struct stat *stat_buf, struct predicate 
*pred_ptr)
+{
+  (void) pathname;
+
+  /* Stat the file (if not already statted) to check the device number. */
+  if (0 == get_statinfo (pathname, state.rel_pathname, stat_buf))
+{
+  return (stat_buf->st_dev == pred_ptr->args.samefileid.dev);
+}
+  else
+{
+  /* get_statinfo will already have 

[bug #54591] gnulib components in findutils do not compile with glibc 2.28

[Kamil Dudka]

Follow-up Comment #5, bug #54591 (project findutils):

I agree but I am not the one who schedules releases here.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57762] Test fail of find.posix/sv-bug-54171.exp

[Kamil Dudka]

Follow-up Comment #2, bug #57762 (project findutils):

This was also reported in Red Hat Bugzilla:
https://bugzilla.redhat.com/1799064

The proposed patch works for me: The test is now skipped when running with
root privileges.

Thank you for taking care of it!

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

Re: [PATCH] find.1: avoid misunderstanding of `-prtinf %Ak` description

[Kamil Dudka]

On Wednesday, October 7, 2020 12:36:56 AM CEST Bernhard Voelker wrote:
> Hi Kamil,
> 
> On 2020-10-06 17:10, Kamil Dudka wrote:
> > * find/find.1 (-printf): Make it clear that strftime() format
> > description in this man page is incomplete and refer to the
> > strftime() documentation instead.
> > 
> > Suggested in https://bugzilla.redhat.com/1882695
> > ---
> > 
> >  find/find.1 | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/find/find.1 b/find/find.1
> > index ee7c6842..0bc882b3 100644
> > --- a/find/find.1
> > +++ b/find/find.1
> > @@ -1420,9 +1420,8 @@ File's last access time in the format returned by
> > the C `ctime' function.> 
> >  File's last access time in the format specified by
> >  .IR k ,
> >  which is either `@' or a directive for the C `strftime' function.
> > 
> > -The possible values for \fIk\fR are listed below;
> > -some of them might not be available on all systems,
> > -due to differences in `strftime' between systems.
> > +Below is an excerpt of possible values for \fIk\fR.  For full list
> > +please refer to documentation of `strftime'.
> > 
> >  .RS
> >  .IP @
> >  seconds since Jan.\& 1, 1970, 00:00 GMT, with fractional part.
> 
> Thanks for the patch.
> 
> I prefer to keep the sentence that the supported list of conversion
> specifiers may vary among different systems.
> 
> Reading the original bug report, I found it useful to add the 'F'
> conversion specifier - yielding the IMO quite useful '-dd-mm'
> date format.

Looks perfect.  Thank you for extending the patch!

> Finally, I added similar clarification to the Texinfo manual.
> 
> May I push the attached in your name?

Sure.  Thanks!

Kamil

> Thanks & have a nice day,
> Berny

[PATCH] find.1: avoid misunderstanding of `-prtinf %Ak` description

[Kamil Dudka]

* find/find.1 (-printf): Make it clear that strftime() format
description in this man page is incomplete and refer to the
strftime() documentation instead.

Suggested in https://bugzilla.redhat.com/1882695
---
 find/find.1 | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/find/find.1 b/find/find.1
index ee7c6842..0bc882b3 100644
--- a/find/find.1
+++ b/find/find.1
@@ -1420,9 +1420,8 @@ File's last access time in the format returned by the C 
`ctime' function.
 File's last access time in the format specified by
 .IR k ,
 which is either `@' or a directive for the C `strftime' function.
-The possible values for \fIk\fR are listed below;
-some of them might not be available on all systems,
-due to differences in `strftime' between systems.
+Below is an excerpt of possible values for \fIk\fR.  For full list
+please refer to documentation of `strftime'.
 .RS
 .IP @
 seconds since Jan.\& 1, 1970, 00:00 GMT, with fractional part.
-- 
2.25.4

Re: findutils-4.8.0-2.fc34.x86_64

[Kamil Dudka]

On Tuesday, August 31, 2021 11:26:15 AM CEST Ricky Tigg wrote:
> Tested on Fedora; findutils-4.8.0-2.fc34.x86_64
> 
> Hello.As noticeable in output resulting from  'find  -name
> ""'' , paths are duplicated.
> 
> $ find /usr/share/icons/ -name "battery*" | head -1
> /usr/share/icons/Adwaita/16x16/devices/battery-symbolic.symbolic.png
> 
> Wouldn't be be that state worth an addition of an option covering the
> following rule: *Do not print source path*. Model of output: that would
> result:
> 
> $ find /usr/share/icons/ -<*Do_not_print_source_path*> -name "battery*" |
> head -1
> Adwaita/16x16/devices/battery-symbolic.symbolic.png
> 
> Regards.

There is already the %P directive of the -printf predicate that does it:

$ find /usr/share/icons/ -name "battery*" -printf '%P\n'

Kamil

[bug #61327] Support for birth time

[Kamil Dudka]

Follow-up Comment #3, bug #61327 (project findutils):

> This directive produces an empty string if the underlying
> operating system or filesystem does not support birth times.

I do not think the above statement is accurate.  On Linux, `find -printf %BT`
produces empty string even if the operating system and filesystem support
birth times.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/