add /dev/tcp/... support

Bug #215034 reported by Martin Fischer on 2008-04-10
32
This bug affects 3 people
Affects Status Importance Assigned to Milestone
bash (Ubuntu)
Wishlist
Unassigned
Nominated for Jaunty by superdug
Nominated for Karmic by superdug
Nominated for Lucid by superdug

Bug Description

Binary package hint: bash

use --enable-net-redirections build flag.

Matthias Klose (doko) on 2008-04-11
Changed in bash:
importance: Undecided → Wishlist
status: New → Confirmed
Tomasz Czapiewski (xeros) wrote :

This extension to bash would be a good thing make some network scripting as it's possible in other (non-debian) distributions. There are at least few scripts which use this extension. For example - google console search scripts ( http://rexio.org/~rush/google.sh ).

Mika Fischer (zoop) on 2008-06-07
Changed in bash:
status: Confirmed → Triaged
Bart Verwilst (verwilst) wrote :

I second this request!

Bart Verwilst (verwilst) wrote :

To add a bit more info, Bash can optionally provide a virtual /dev/tcp and /dev/udp which can be used to request output from a udp/tcp port. This works on many other distributions and is a really great feature of Bash.. it's a shame that this isnt enabled.

trekvarten (david-flemstrom) wrote :

This feature might open security holes.
Still it's really useful, +1

Bart Verwilst (verwilst) wrote :

What kind of security holes might it open? You can just connect to a port.. same thing as with wget/curl/netcat... but directly from bash, which makes it pretty handy.

Juliano Ravasi (jravasi) wrote :

Another request to fix this. It is a really simple fix, it only needs to remove the "--disable-net-redirections" configure option added by Debian and bring bash closer to what it was intended to be by its developers.

The Debian maintainer gave this justification in /usr/share/doc/bash/README.Debian.gz :

    9. Why is bash configured with --disable-net-redirections?
        It can produce completely unexpected results. This kind of
        feature should not be part of a shell but a special tool. And
        that tool has existed for years already, it's called netcat.

In my opinion, this is completely unreasonable.

The first argument, that "It can produce completely unexpected results" is just plain wrong. It is precisely documented, the names were chosen in order to not conflict with real files (no known unix system have "/dev/tcp" or "/dev/udp" hierarchies), and is part of the expected features of bash.

The second argument, that "This kind of feature should not be part of a shell but a special tool." is also invalid. Anyone who used both netcat and bash net redirection knows that this bash feature is much more flexible than netcat. Using netcat you can't access both input and output channels easily due to limitations on how shell pipelining works. You can easily redirect the input from a file, process or subshell, and you can easily redirect the output to another file, process or subshell. But it is insane to get both input and output of a process in the parent process using only common shell redirections. This severely limits what can be done with netcat, and is the very reason why bash implemented this feature.

Bash net redirection allows that, very easily:

    exec 99<>/dev/tcp/server/port
    echo >&99 "Message 1"
    read -u 99 response1; echo $response1
    echo >&99 "Message 2"
    read -u 99 response2; echo $response2
    echo 99>&-

The origin of this bug, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=65172 , has a really ridiculous discussion, IMO. The report was about an unrelated issue, they freaked out that bash was too bloated, then with what happens if the user has something under /dev/tcp (ignoring that it doesn't make any sense to have anything there, it was chosen for this reason, and that the user is not supposed to make such kinds of modifications to the system), and then it was decided that disabling the feature would solve the bug.

If the user gets himself to a bash shell, he is probably smart enough to deal with bash features, and would probably make very good use of them. There were very strong reasons for this feature to be added to bash, and a very dumb arguments for it to be originally disabled in Debian.

Ken Gilmer (kgilmer) wrote :

Here here. There maybe some reason for not having this feature but the stated motivations are not it. +1 for adding /dev/tcp.

tyler (tyler-chickn) wrote :

also +1.
also, why isn't there a feature in launchpad to just let me vote +1 on this? ;) (is there?)

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package bash - 4.0-4ubuntu1

---------------
bash (4.0-4ubuntu1) karmic; urgency=low

  * Merge with Debian; remaining changes:
    - Build from the upstream sources, build the documentation in info format.
    - /etc/skel/.bashrc: eval lesspipe.
  * Changes to the skeleton .bashrc:
    - Source .bash_aliases after defining aliases. LP: #400686.
    - Enable color support for grep. LP: #386502.
  * The bash docs now describe uname -s not having any effect on many
    systems. LP: #378595.
  * Don't ship an info dir file. LP: #358932.
  * Fix some lintian warnings.

bash (4.0-4) unstable; urgency=low

  * Apply upstream patches 024 - 028.
    - patch 028 closes: #519165. bash-4.0 reverted to the historical
      shell behavior of raising an error when $@ or $* was expanded
      after `set -u' had been executed and there were no positional
      parameters. The Posix working group has since clarified the
      standard's position on the issue, and $@ and $* are now the only
      variables, parameters, or special parameters that do not raise an
      error when unset if set -u is enabled.
  * Enable net redirections, now that bash isn't the default shell
    anymore. LP: #215034.
  * Changes to the skeleton .bashrc:
    - Fix example lines in /etc/bash.bashrc to enable bash completion.
      Closes: #523706, #522857.
    - Don't export HISTCONTROL in bashrc. Closes: #540371.
    - Support user dircolors settings in ~/.dircolors. Closes: #506213.

bash (4.0-3) experimental; urgency=low

  * Apply upstream patches 011 - 024.

bash (4.0-2) experimental; urgency=low

  * Apply upstream patches 001 - 010. Closes: #518289.
  * Fix insecure temp file handling in examples scripts. Closes: #509279.
  * /etc/skel.bashrc: Only source bash_completion, if posix mode is turned
    off. Closes: #498474.

bash (4.0-1ubuntu1) jaunty; urgency=low

  * Merge with Debian; remaining changes:
    - Build from the upstream sources, build the documentation in info format.
    - /etc/skel/.bashrc: eval lesspipe.

bash (4.0-1) experimental; urgency=low

  * New upstream version 4.0.

bash (4.0-0ubuntu1) jaunty; urgency=low

  * New upstream version 4.0 beta.

 -- Matthias Klose <email address hidden> Mon, 24 Aug 2009 12:06:59 +0200

Changed in bash (Ubuntu):
status: Triaged → Fix Released

It's not fixed at all!
It's not released at all!
As of Ubuntu 9.04 (jaunty).

Uqbar (uqbar) wrote :

I confirm the /dev/tcp is not in place as of Jaunty,

willdye (willdye) wrote :

Just in case anyone ever lobbies to disable /dev/tcp in Bash again, I want to add my support to leaving it enabled. Lots of languages have features which are dubious at best ("leading zero means octal", for example), but distributions tend to leave those features in place because the languages are already widely used.

Because of Ubuntu, some of my Bash scripts have already been (in effect) split into two versions -- one for older Ubuntu distributions, and one for Red Hat & everything else. Granted, this sort of split is all too common, and caused by far more than just /dev/tcp support. The point remains that anytime a distributor second-guesses a language implementation decision, it means that programs which have worked correctly for years on multiple systems will suddenly stop working on your distribution.

I agree that there are times when backward compatibility must give way to modern security, but breaking existing programs should be a method of last resort. Instead, we have an opinion that a long-standing language feature would have been better handled by an external program, and an accusation that improper usage of the feature can lead to "unexpected results". That is nowhere near a strong enough argument to merit breaking existing programs which work just fine on several other platforms.

superdug (superdug) wrote :

I'm confused, it says in the changelog that enable net extensions per update #9, yet with the following installed:

ii bash 4.0-5ubuntu2 The GNU Bourne Again SHell
ii bash-builtins 4.0-5ubuntu2 Bash loadable builtins - headers & examples
ii bash-completion 1:1.0-3ubuntu2 programmable completion for the bash shell
ii bash-completion-lib 1.3.1-2 programmable completion for the bash shell
ii bash-doc 4.0-5ubuntu2 Documentation and examples for the The GNU B
ii bash-minimal 4.0-5ubuntu2 The GNU Bourne Again SHell (minimal version)
ii bash-static 4.0-5ubuntu2 The GNU Bourne Again SHell (static version)
ii bashdb 4.0.0.2-1 BASH debugger
ii mybashburn 1.0.2-1 Burn data and create songs with interactive

There still appears to be no /dev/tcp support.

Changed in bash (Ubuntu):
status: Fix Released → Confirmed
superdug (superdug) wrote :

Sorry to reopen a closed bug. This is in fact fixed in Karmic 9.10 status changed back.

Changed in bash (Ubuntu):
status: Confirmed → Fix Released
superdug (superdug) wrote :

exec 3<>/dev/tcp/www.google.com/80
echo -e "GET / HTTP/1.1\n\n">&3
cat <&3

Will in fact get you the index page from google. However you won't see a /dev/tcp if you look in /dev it is intercepted by bash itself. Also worth noting that bash is not the default shell in ubuntu 9.10, it is dash.

/bin/bash is where the binary for the shell is located

strings /bin/bash | grep -iE "tcp|udp"
/dev/tcp/*/*
/dev/udp/*/*

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.