linux-kernel - Re: May close() return any error code?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150802135723.GC17109@ZenIV.linux.org.uk>
Date:	Sun, 2 Aug 2015 14:57:23 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Pavel Machek <pavel@....cz>
Cc:	Takashi Iwai <tiwai@...e.de>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	"Dr. Werner Fink" <werner@...e.de>
Subject: Re: May close() return any error code?

On Sun, Aug 02, 2015 at 09:42:20AM +0200, Pavel Machek wrote:
> > This seems coming from evdev_flush().  As there is no fd leak, it's no
> > big problem per se.  But, now the question is whether returning such
> > an error code is correct behavior at all.  At least, it doesn't seem
> > defined in POSIX:
> >
> http://pubs.opengroup.org/onlinepubs/009695399/functions/close.html
> 
> Returning an error from close() would imply that file descriptor is
> not closed.... seems like bad idea. Just fix the kernel not to do it.

The only thing implied here is failure to RTF{M,S}.  To quote close(2):

NOTES
       Not checking the return value of close() is a common  but  nevertheless
       serious  programming error.  It is quite possible that errors on a pre‐
       vious write(2) operation are first reported at the final close().   Not
       checking the return value when closing the file may lead to silent loss
       of data.  This can especially be observed with NFS and with disk quota.
       Note  that  the  return  value should only be used for diagnostics.  In
       particular close() should not be retried after an EINTR since this  may
       cause a reused descriptor from another thread to be closed.

That's Linux one.  FreeBSD one says

     In case of any error except EBADF, the supplied file descriptor is deal-
     located and therefore is no longer valid.

and that matches behaviour of historical BSD variants as well.  POSIX is being
its usual charming self and says "if a kernel shipped by $VALUED_MEMBER does
this and that cretinous thing, far be it from us to call it broken".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/