Bug 443321

(In reply to comment #0)
> Description of problem:
> With the current autofs code I seem to see occasionally a leaked file descriptor
> which manifests itself as an SELinux problem (see below).  I don't know how it
> triggers.  I use autofs's /net mount point.  Beside that I have a removable MMC
> on that machine but that's handled by HAL, I think.

We know about this.

I believe the problem is that a descriptor can sometimes
be open but not yet have close-on-exec set when we fork
a mount(8) or umount(8).

The approach of sequentially closing a bunch of descriptors
on every fork isn't a good idea because the highest numbered
descriptor could be quite high.

I'm aware that it's possible to set the close-on-exec atomically
at open with recent kernels (and I guess glibc supports this) but
I can't be sure that is available on all kernels and glibc's that
autofs may be used with.

Have a look at bug RHEL-5 bug 233481 where the problem has been
discussed and a couple of patches posted. The patch in that
bug which uses a mutex around open and set close-on-exec was
present in Rawhide for a while but attracted some criticism
regarding performance and concern over not using atfork handlers.
Personally, I don't think I need to use these handlers, provided
I'm careful, since we always do an exec following a fork. Do
you think using atfork handlers with a mutex would give better
performance?

I'd appreciate you're opinion on this.

Ian

(In reply to comment #1)
> I'm aware that it's possible to set the close-on-exec atomically
> at open with recent kernels (and I guess glibc supports this) but
> I can't be sure that is available on all kernels and glibc's that
> autofs may be used with.

What you should do is use the flag anyway.  Older kernels will ignore it.  Then
test afterwards whether it works.

In glibc I have a global variable which indicates whether the flag is honored. 
I set it after the first use of the O_CLOEXEC.  This allows to skip the fcntl()
calls for the later open calls.

int have_cloexec;

{
  ...
  fd = open(..., ...|O_CLOEXEC|...)
  if (have_cloexec <= 0)
    {
      int fl = fcntl(fd, F_GETFD);
      have_cloexec = (fl & FD_CLOEXEC) != 0 ? 1 : -1;
      if (have_cloexec < 0)
        fcntl(fc, F_SETFD, fl|FD_CLOEXEC);
    }

(In reply to comment #2)
> (In reply to comment #1)
> > I'm aware that it's possible to set the close-on-exec atomically
> > at open with recent kernels (and I guess glibc supports this) but
> > I can't be sure that is available on all kernels and glibc's that
> > autofs may be used with.
> 
> What you should do is use the flag anyway.  Older kernels will ignore it.  Then
> test afterwards whether it works.

Right, that's a good start.
I'll do that.

Ian

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

See

  http://udrepper.livejournal.com/20407.html

For more information on the new functionality.  The calls are now in the rawhide kernel and glibc.  To create a socket, for instance, use this:


  #ifdef SOCK_CLOEXEC
    fd = socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC, 0);
    if (fd == -1 && errno == EINVAL)
  #endif
      {
        fd = socket(AF_INET, SOCK_STREAM, 0);
        fcntl(fd, F_SETFD, FD_CLOEXEC);
      }

*** This bug has been marked as a duplicate of bug 390591 ***