Write More Bits

Bash通过/dev/proto/host/port这一方式，提供给用户直接通过最基本的read/write命令用proto指定的网络协议来访问host:port这个端口的能力。举个例子，我们通过tcp协议，来访问time.nist.gov的13端口来获得当前的网络时间：

cat </dev/tcp/time.nist.gov/13

或者，更复杂的，获取google的主页:

exec 3<>/dev/tcp/www.google.com/80
echo -e "GET / HTTP/1.1\r\nhost: http://www.google.com\r\nConnection: close\r\n\r\n" >&3
cat <&3

当然，/dev/proto这个字符串，Bash会负责解释，它并没有对应到真正的文件系统中的节点，所以，你不会在/dev目录下看到tcp这个文件，^_^
http://www.linuxjournal.com/content/more-using-bashs-built-devtcp-file-tcpip

做日常的Linux管理，很多时候需要用bash写个CGI，确实很方便，下面的这个链接是个很不错的入门材料，在此记录一下：
http://foxlx.acmesystems.it/?id=165

今天，尝试将一个操作防火墙的脚本加上setuid标志位，以让普通用户也能在一定条件下，通过认证，添加自己需要的防火墙规则，发现，在脚本之上的setuid标志位居然不起作用，后来search了一下，才知道，原来setuid和setgid都只能用在可执行的binary上，而不能在脚本之上的setuid和setgid无效。
想一想，这样貌似不太合理，究竟二进制文件和脚本文件有什么分别呢。linux内核执行二进制的时候，会检查其标志位，如果有setuid或者getgid，就会将进程的effetive user和effective group设置成相应的用户和组。当内核发现，要执行的不是一个二进制文件，而是一个脚本文件，内核就会读它的第一行，获得“#!”之后的字符串，作为解释器，为解释器启动进程，然后将脚本文件作为参数，传给解释器。貌似，这个过程，解释了，为什么脚本上设置的setuid没有作用，因为真正的脚本解释进程，并没有以相应的effective user来运行。但是，linux内核也完全可以以脚本setuid的user来运行解释器，但是内核没有这么做，这其中的原因，我暂时也没想明白，呵呵
下面这篇文章就是我搜到的，在此记录一下：
http://serverfault.com/questions/8449/cannot-set-uid-on-shell-scripts

http://codex.wordpress.org/Excerpt