Closed MeindertKempe closed 3 years ago
I am having the same problem after upgrading from 0.22.11
to 0.23
.
First of all, the log you posted does not reflect your description. It does not show a failed status
. Please post a new log.
connecting from localhost only
default_permissions
are given.
Of course. Why would localhost be special? Are you mixing up "regular TCP connection from loopback device" (what you're doing) with "clients connecting on a local socket" (what local_permissions
is defined for)?
(A "local socket" is sometimes called "UNIX domain socket", and is a special kind of connection without TCP and without a network device.)
I doubt that this ever worked for you.
Expected Behavior
running
mpc --host=password@localhost status
returns the status
I tried with your configuration, and this actually returns the status.
running
mpc --host=localhost status
returns status
And this worked for me, too.
running
mpc --host=localhost play
starts playing
This does not work, by design, as I explained above.
The only thing that's really broken for you is the "No permission for status" with password. Works for me. What you can do is do a git bisect
, that's the only thing that appears useful to me.
And I'm really curious about the "localhost" problem. Please bisect that as well - what was the most recent commit that still worked? As I said, I doubt this has ever worked, and I think this bug report is wrong, but maybe you can prove me wrong.
Authentication appears to have also broken for me on the 0.23 release. With authentication set up:
password "mympdpassword@read,add,control,admin"
Upon running mpc --host=mympdpassword@localhost status
, I get MPD error: you don't have permission for "status"
, and this is output to my logs:
Oct 17 01:21 : client: [0] opened from 127.0.0.1:50324
Oct 17 01:21 : client: [0] process command "password "mympdpassword""
Oct 17 01:21 : client: [0] command returned 0
Oct 17 01:21 : client: [0] process command list
Oct 17 01:21 : client: process command "status"
Oct 17 01:21 : client: command returned 3
Oct 17 01:21 : client: [0] process command list returned 3
Oct 17 01:21 : client: [0] closed
Looks like on my machine, ncmpcpp, mpc, and mpd-mpris cannot authenticate with the latest release.
@justin-sleep, please bisect (works for me, sigh)
After investigating further, I think this might just be a problem with Arch's package for 0.23. I can't reproduce this with the source code, even when using the same files and build configuration as Arch's package.
After investigating further, I think this might just be a problem with Arch's package for 0.23. I can't reproduce this with the source code, even when using the same files and build configuration as Arch's package.
That's what i experienced too... Reported a bug here: https://bugs.archlinux.org/task/72454
Hm, I wonder how a distribution can break their MPD package - what's causing this bug?
In case anybody wants to report another bug: the Arch package has left debugging enabled - release builds should configure with -Db_ndebug=true
.
I'm closing this bug - we can reopen this if it turns out that this Arch bug is really caused by a MPD bug.
I did some testing with different build configurations on my Arch system regarding the authentication issue.
It seems something inside handle_password()
breaks when enabling compiler optimizations.
compiler / flags | status |
---|---|
gcc v11.1.0 without optimizations |
works |
gcc v11.1.0 with -O1 or larger |
broken |
clang v12.0.1 with -O1 or less |
works |
clang v12.0.1 with -O2 or larger |
broken |
The assembly output in gdb suggests that the permission
variable in handle_password()
is optimized away and assumed to be always 0
. This results in a "hardcoded" client.SetPermission(0)
effectively not granting any permissions:
0x000000000005826a <+138>: movl $0x0,0x20f0(%rbx)
I did not have time to do further checks with older versions of gcc/clang or enabling only specific optimizations. However, I am not sure whether this is to be considered a bug of MPD or of the compiler.
MPD v0.22.11 built with identical options, compiler versions and flags works as expected however.
Thanks @tryone144, that was the right hint - there's a misplaced pure
attribute:
https://github.com/MusicPlayerDaemon/MPD/blob/771c46032f4dd60097d46524ef6873a49b051a01/src/Permission.hxx#L35-L37
This breaks because the function has an output parameter, which is a side effect. Of course, output parameters are a bad design, and should be replaced with a std::optional<unsigned>
return type.
Anybody up to writing a PR for this?
Bug report
Describe the bug
In mpd version 0.23 authentication seems entirely broken, trying to connect with a password gives no permissions and connecting from localhost only
default_permissions
are given.Relevant config:
Expected Behavior
running
mpc --host=password@localhost status
returns the statusrunning
mpc --host=localhost status
returns statusrunning
mpc --host=localhost play
starts playingActual Behavior
running
mpc --host=password@localhost status
returnsMPD error: you don't have permission for "status"
running
mpc --host=localhost status
returns statusrunning
mpc --host=localhost play
returnsMPD error: you don't have permission for "play"
Version
Log