Ok, the part on the protocol sounds good, and I can also save on the atty flag.

Actually, on this note, I am not too happy with all the branching logic either. What do you think about factoring out the common logic (eg. permission check) and having two different functions, one for TTYs.

But we might want to put some further thought into this first. Right now the behaviour of su in pipes is not completely correct. For example,
```
echo "foo bar" | su -c /system/bin/less
```
doesn't behave as expected, because su's stdout is a TTY, so it asks for a pseudo-terminal from the daemon. However, that means less' stdin is now also a terminal, so it adopts fully interactive behaviour, and doesn't accept input to display on stdin. However, if we change the atty check to look at stdin, then less will not be able to display the output correctly, because its output is now attached to FIFOs.

I think we need to look at each I/O stream (stdin, stdout, stderr) and process them separately, establishing a pty in the daemon where the su client's I/O stream is attached to a tty, or a FIFO otherwise. But this also sounds like a large change, and I'm inclined to leave it for a later commit, and just get the basics right first.