Let me preface this ticket by stating:
Yes, I am aware that
--password-file is intended to only be used for clients. I discovered this particular issue after trying to sort out why the automated tests were failing via some trial-and-error (read: disabling features until they finally started working again). As a temporary workaround I've disabled the password authentication for the tests, but I feel there is a bug here in that we don't handle this flag properly (even if it's being misused).
This was tested when trying to start a session on a Fedora 26 machine running a beta
xpra v2.3-r17837 package from the beta repository.
The server was started with:
xpra start :15 --bind-tcp=0.0.0.0:10000 --start-child=xterm --start-via-proxy=no --systemd-run=no --tcp-auth=file,filename=password.txt --password-file=password.txt -d auth, and I get an immediate traceback:
Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 175, in main return run_mode(script_file, err, options, args, mode, defaults) File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 1501, in run_mode return run_server(error_cb, options, mode, script_file, args, current_display) File "/usr/lib64/python2.7/site-packages/xpra/scripts/server.py", line 473, in run_server opts.password_file = os.path.abspath(opts.password_file) File "/usr/lib64/python2.7/posixpath.py", line 360, in abspath if not isabs(path): File "/usr/lib64/python2.7/posixpath.py", line 54, in isabs return s.startswith('/') AttributeError: 'list' object has no attribute 'startswith'
Running it again without the
--password-file= makes the traceback go away, and the session starts as expected.
Note, I was testing the server start arguments with regards to how the automated tests start the server; specifically the authentication section when I stumbled across this traceback.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1740