Exposing /proc
and /dev
exposes some more information and grants more rights to the users inside the jail.
Beware that uids and gids may be different inside and outside the jail. For instance, inside the jail, user "x" may be member of group 123, which in the jail is for "users" while on the system is for "disk". By bind-mounting /dev
, you would grant them access to raw disk devices which would allow them virtually root access and get out of the jail.
I would not bind-mount /dev. Only create a few devices in there that the java application may need (null
, tty
, zero
...) with the proper ownership and rights.
Have you considered linux containers instead of chroot jails which would isolate them more (lxcs are just a step further to chroot jails).
That's shell dependant and not documented AFAICS. In ksh
and bash
, in the first case, foo
will share the same stdin as bar
. They will fight for the output of echo
.
So for instance in,
$ seq 10000 | paste - <(tr 1 X)'
1 X
2 X042
3 X043
4 X044
5 X045
[...]
You see evidence that paste
reads every other block of text from seq
's output while tr
reads the other ones.
With zsh
, it gets the outer stdin (unless it's a terminal and the shell is not interactive in which case it's redirected from /dev/null
). ksh
(where it originated), zsh
and bash
are the only Bourne-like shells with support for process substitution AFAIK.
In echo "bla" | bar < <(foo)
, note that bar
's stdin will be the pipe fed by the output of foo
. That's well defined behaviour. In that case, it appears that foo
's stdin is the pipe fed by echo
in all of ksh
, zsh
and bash
.
If you want to have a consistent behaviour across all three shells and be future-proof since the behaviour might change as it's not documented, I'd write it:
echo bla | { bar <(foo); }
To be sure foo
's stdin is also the pipe from echo
(I can't see why you'd want to do that though). Or:
echo bla | bar <(foo < /dev/null)
To make sure foo
does not read from the pipe from echo
. Or:
{ echo bla | bar 3<&- <(foo <&3); } 3<&0
To have foo
's stdin the outer stdin like in current versions of zsh
.
Best Answer
On Linux,
/dev/fd
is a symbolic link to/proc/self/fd
, where/proc/self
is a symlink to the process directory of the calling process./proc/$pid/fd
then contains magic links to the open filehandles. Bash uses that to make pipes that can be accessed by filename without needing to leave anything on the actual filesystem.So, you'd need to mount
/proc
and make the/dev/fd
symlink.Alternatively, you could see if it's possible to get Bash to use named pipes on the filesystem, according to the manual, it should be an option:
But that seems to require a re-compile. The
configure
script automatically detects if/dev/fd
is available, but you can disable it inconfig.h
, delete the line(Or change it to
#undef HAVE_DEV_FD
to make sure. And don't make the mistake I did: changing the1
to a0
doesn't work.)With those settings, you get
Though if you do that with
ls
or some other command that doesn't actually go and read the pipe, both the pipe and a shell process are left lying around.