Do not clear DISPLAY variable unconditionally

[mruprich]

A while ago as a reaction to this bug - #176 - rsync started clearing the DISPLAY env variable during start-up. rsync has no knowledge of the use of DISPLAY in the system so it should not clear the variable unconditionally. The unconditional clearing of the variable breaks the usage of SSH_ASKPASS for instance:

SSH_ASKPASS If ssh needs a passphrase, it will read the passphrase from the current terminal if it was run from a terminal. If ssh does not have a terminal associated with it but DISPLAY and SSH_ASKPASS are set, it will execute the program specified by SSH_ASKPASS and open an X11 window to read the passphrase. This is particularly useful when calling ssh from a .xsession or related script. (Note that on some machines it may be necessary to redirect the input from /dev/null to make this work.)

Clearing DISPLAY breaks the usage of the above ssh option. rsync should not assume that DISPLAY should be cleared every time. Simple reproducer in Fedora on a single machine below:

# dnf -y install sshpass
# useradd test
# useradd test1
# echo test | passwd --stdin test
# echo test1 | passwd --stdin test1
# su - test1
$ mkdir receiver
$ logout
# su - test
$ ssh-keygen -q -N VERYSECRETPASSPHRASE -f /home/test/.ssh/id_rsa
$ ssh-keyscan 10.0.185.46 >> .ssh/known_hosts  <--- ssh-copy-id won't work without this
$ sshpass -p test1 ssh-copy-id -i .ssh/id_rsa.pub test1@10.0.185.46
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: ".ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keysNumber of key(s) added: 1Now try logging into the machine, with:   "ssh 'test1@10.0.185.46'"
and check to make sure that only the key(s) you wanted were added.$ mkdir sender
$ for i in {1..10}; do echo file$i > sender/file$i; done
$ cat > /tmp/echo_passphrase.sh<< EOF
#!/bin/sh
echo "VERYSECRETPASSPHRASE"
EOF
$ chmod 0755 /tmp/echo_passphrase.sh
$ export DISPLAY=:123.456; export SSH_ASKPASS=/tmp/echo_passphrase.sh
$ rsync -avz --rsh='setsid /usr/bin/ssh -S none -i /home/test/.ssh/id_rsa -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null' sender/ test1@10.0.185.46:/home/test1/receiver

Permission denied, please try again.
Permission denied, please try again.
test@10.0.186.166: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
[sender] _exit_cleanup(code=12, file=io.c, line=228): entered
rsync error: error in rsync protocol data stream (code 12) at io.c(228) [sender=3.2.5]
[sender] _exit_cleanup(code=12, file=io.c, line=228): about to call exit(12)

[mruprich]

Another solution here would be to simply revert the original fix. The initial problem and hang was in dbus, not rsync. Seems to me like the bugfix solved one particular usecase of dbus bug but I don't think it justifies this being in rsync forever.