DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=wGQKsT6pQRhSTsPhuP6kvbXViCoOg8Umnnbs1RxpWQrbtPPPkElu0
	0JLQj2Aakq2+kYrXg46pzMyfG9lLsH2zfLtuwkI0j7RS5d7ctQcACBF3VQ6tmeSi
	jybQHcsSqkQXaxsS5OWIjT3EpIyTAfP5Yr/IDLRMlfgVaH9q0gKqqA=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Mon, 17 Dec 2018 10:25:33 +0100
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: /dev/fd/N not synonymous with file descriptor N; it is on Linux
Message-ID: <20181217092533.GP28727@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <0f030e809f063f5a5e64ff7a7a0c3227@xs4all.nl> <20181216202847.GK28727@calimero.vinschen.de> <CAHSx_SvqFgi5stKvYSNCPwyyu98miPHyYcDKJL1-=KP8NE9+JQ@mail.gmail.com> <20181216215549.GO28727@calimero.vinschen.de> <12270f528754c1ce974e6ad8d22c4249@xs4all.nl>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="j2AXaZ4YhVcLc+PQ"
Content-Disposition: inline
In-Reply-To: <12270f528754c1ce974e6ad8d22c4249@xs4all.nl>
User-Agent: Mutt/1.9.2 (2017-12-15)

--j2AXaZ4YhVcLc+PQ
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Dec 17 05:30, Houder wrote:
> On 2018-12-16 22:55, Corinna Vinschen wrote:
> [snip]
>=20
> > I'm mulling over adding some hack to open().  It could try to recognize
> > the special case of opening a processes' own descriptor symlink within
> > /proc and then warp the open() call into dup().  No idea how tricky
> > or even feasible that is, though...
>=20
> That is why I wrote the following in my STC:
>=20
>         // Q: does Cygwin attempt to read the /tmp directory? (an attempt
> that
>         //    will fail, because the file has been unlinked)
>         // it appears that reading a symlnk in /dev/fd can best be divert=
ed
> to
>         // the open file descriptor of the process ...
>=20
> What I meant was, that I see no reason to modify the symlink in this
> special case, but in stead of that to access the file using fd N, where
> N is equal to the one in /dev/fd/N.
>=20
> File descriptor N has been left open by bash and should not have been
> closed as result of the exec ...

tl;dr:

  cat tries to open /dev/fd/0.  /dev/fd/0 refers to a non-existing
  file and that's why open fails.  Cygwin doesn't have special code to
  handle the fd symlinks as refference to an actually open descriptors.

The long story:

  The descriptor hasn't been closed.  Cat still has the file open as fd 0.

  The problem is that you tell cat to open and read from /dev/fd/0,
  *not* from fd 0.  That's quite a difference.  /dev/fd/0 is just some
  arbitrary file which is given to open(2), a symlink at that.  First
  thing open(2) does is to call the symlink evaluation code.  The
  symlink is ultimately evaluated to the filename opened by the shell.

  So, cat's open(2) tries to open "/tmp/whatever".  But, as you noticed,
  that path doesn't exist anymore since it has been deleted by the shell
  before even writing to it via unlink(2).

  What happens is that unlink(2) is supposed to delete a file in use.
  Since that's not possible in Windows, the file gets renamed into the
  recycle bin and just marked for deletion.

  The fact that the filename changed is not known to the application of
  course, it just gets success reported from unlink.  Cygwin itself
  doesn't know the new name of the file either.  There just isn't a
  reason to keep track since it's going to be removed anyway at one
  point.

  And even *if* we keep track, we can't use this information since files
  marked for deletion can't be opened on Windows (ERROR_DELETE_PENDING
  or ERROR_ACCESS_DENIED, I'm not sure which).

  Here's another problem with handling /dev/fd/0 as just some descriptor
  we can call dup(2) on:

  /dev/fd/0 is just some symlink which evaluates like this:

  - /dev/fd is a symlink to /proc/self/fd
  - /proc/self is a symlink to /proc/<current_process_pid>

  So before we even get to evaluate fd 0 symlink, we're at

    /proc/<current_process_pid>/fd/0

  Here's the question:  What if you don't give /proc/self/fd/0 to
  cat, but something like /proc/<some_other_processes_pid>/fd/0?

  That's where Cygwin just fails because /proc is a process-local fake
  in our user space Cygwin DLL.  Emulating /proc is fun stuff, the full
  functionality is pretty tricky without going to great lengths like
  starting a service with SYSTEM permissions.

  Bottom line is, we could do more if we decide that running cygserver
  is a requirement.  As it is, we always strived for a setup which
  works "out of the box", without having to start services and stuff.


Corinna

--=20
Corinna Vinschen
Cygwin Maintainer

--j2AXaZ4YhVcLc+PQ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlwXa40ACgkQ9TYGna5E
T6DECw/+NzRN0Pzt9r3BgUIvfAC/g+h9orX9LsAg4uzRbp9wBBPDs2AX7GLMtlwt
1NCVK3kcuOwnDJ7dNLxULdMAc3oensXZHtB6ouvBlIpk8ChHAXbPCZY/VkQHWfHR
AC2cALCMUCfZsHU/JZLBvxK02uL5gVGK0RCnFQ40q5HPdl6x/ynFmbWM0CHi+yag
2eXvbaqRa+VTU2nI+LX5/d1P5DjtVm5H9OtFO8n8MZMiDYKMF0UKsIw8VWZW5xAJ
3DvKUPCUOkaqzh9rPyN35Qxbnd0RPt7Ki4LKPD/WypeLv0L75uEYNYHOEAJVs7WK
9mqg77CwgDw4ECX6jJsAr2P1mMG1GokHef3rydmMtLwsbzby4iB6p/gPB5xUCJp/
nslk9PupOnpGtdyPkG/T0mJupjNFY239cinHgIXFQSoDONOQWWqV0fKzPDEoGznA
O4CVkoosgHvFeF7H32qqn17gm4Td4B47uEzsD+dg5Xl54+zrFLVxH0smoV6Zd/Gl
vDlOuY65OxcH+Is97fl8Z3CE23aVpKk/JjvRbDW9XbUwAfla9TIo2+Mf0GKHd/Rd
85naMIm6Ow3Nr/RMuq3lp6/YC5ofSBi1PV4EhKNlm3QSqvs8BN8tiYlEslcYDGk9
k0MMwtRAJUJDScOklRb2oA51+fabJYoRxd7n9hmCqZQOQ5ILPC8=
=AbvH
-----END PGP SIGNATURE-----

--j2AXaZ4YhVcLc+PQ--