On Aug 27 18:13, Cary Lewis via Cygwin wrote: > In a cygwin process that is started either from mintty or bash directly the > following: > > $ user=234 > > $ ./cat <(echo $user) > 234 > works as expected. > > But after a chroot:
>From https://cygwin.com/cygwin-ug-net/highlights.html: chroot is supported. Kind of. Chroot is not a concept known by Windows. This implies some serious restrictions. First of all, the chroot call isn't a privileged call. Any user may call it. Second, the chroot environment isn't safe against native windows processes. Given that, chroot in Cygwin is only a hack which pretends security where there is none. For that reason the usage of chroot is discouraged. Don't use it unless you really, really know what you're doing. > $ chroot . ./bash > user=234 > $ ./cat <(echo $user) > ./cat: /dev/fd/63: No such file or directory > > In the directory I am chrooting in, I created a tmp folder, as well as > proc, proc/self, and proc/self/fd, and a dev directory. > > Can someone explain why process substitution to create a virtual file > doesn't work in a chroot environment? /dev/fd is a symlink pointing into nirvana after using chroot. /dev/fd symlinks to /proc/self/fd, but in the chroot'ed environment there's no /proc anymore. I would like to underline what is written in the above Cygwin documentation snippet: The chroot implementation is old, bad, and deprecated. I was going to rip it out entirely for I don't know how often already, but there was always somebody asking to keep it. Given that it never did what chroot is intended, don't use it. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
