address@hidden: coreutils problem]

[Michael Stone]

I can readily duplicate this bug report on a 2.6.24-rc7 kernel by 
running `ls -l /proc/sys/fs/inotify`

Kernel bug? libselinux bug? Documentation bug? 

I suppose coreutils should check that the returned context is non-NULL. 
It looks like the debian 5.97-5.3 selinux patch (derived from redhat) 
never even looks at the return value of getfilecontext, which doesn't 
seem right, either. Does the attached patch make sense?

----- Forwarded message from Jan Moringen -----

From: Jan Moringen 
Subject: coreutils problem

Hi.

Let met first apologize in case I'm writing to the wrong person, but I
encountered a very odd problem and am a bit confused who to talk to :) I
would have filed a proper bug report, but I have no idea who the culprit
is and therefore which package (or upstream as I don't know if the
problem is Debian-related or not) to file it against.

The problem is that ls crashes when requesting a long listing for
certain files:

 address@hidden inotify]$ pwd
 /proc/sys/fs/inotify
 address@hidden inotify]$ ls -l
 Segmentation fault
 address@hidden inotify]$ 

I can provide details about my system or file a proper bug report if
desired, but I would have to know where to report the bug then. Maybe
the rest of this mail is useful in figuring out where to report the bug.

Thank you in advance.

Sincerely,
Jan Moringen

I traced the problem to this piece of code in ls.c:2664-2672:

 2664 bool have_acl = false;
 2665 int attr_len = (do_deref
 2666                 ?  getfilecon (absolute_name, &f->scontext)
 2667                 : lgetfilecon (absolute_name, &f->scontext));
 2668 err = (attr_len < 0);
 2669
 2670 if (err == 0)
 2671   have_acl = ! STREQ ("unlabeled", f->scontext);
 2672 else

The problem is that getfilecon() returns 0, which the caller considers a
success, but does not touch f->scontext. scontext is of type
security_context_t which is a typedef for char*. The resulting invalid
pointer is dereferenced in line 2671.

I'm not sure whether this code is wrong because getfilecon() is not
supposed to ever return 0 as far as I can tell. This is from the
getfilecon(3) manpage:

 RETURN VALUE
   On success, a positive number is returned indicating the  size of  
   the extended  attribute value. On failure, -1 is returned and errno 
   is set appropriately.

I attached a small program that reproduces the suspicious behavior of
getfilecon on my system. I am well aware that it probably won't work on
too many other systems. Otherwise somebody would have found that problem
by now I suppose.


#include <stdlib.h>
#include <stdio.h>
#include <errno.h>

#include <selinux/selinux.h>

int
main(int argc, char* argv[]) {
 security_context_t context = 0;

 int res;
 if ((res = getfilecon("/proc/sys/fs/inotify", &context)) < 0)
   printf("getfilecon() failed %s\n", strerror(errno));
 else
   printf("getfilecon() succeeded: %d\n", res);

 printf("context %x\n", context);
 if (res && context)
   printf("context %s\n", context);

 return EXIT_SUCCESS;
}


----- End forwarded message -----

73_ls_getfilecon
Description: Text document