[systemd-devel] Cannot call GetUnit method with ssh

[Bao Nguyen]

Hi Lennart & Mantas,

Thanks a lot for your quick response.

Maybe you're right, dbus-daemon resolves users mentioned in its policy
files at start-up. And then adding a new user to LDAP, dbus-daemon has
not resolved yet so it do not allow to access system bus. That may be
the reason that restart dbus resolve the issue, mean makes dbus aware
the new user. However, as Mantas said he does not meet the issue with
LDAP account, could Mantas please add a new LDAP account again to
confirm if you meet the same problem or not, or any new LDAP account
added you do not see the issue without restart dbus?

BTW, I remember I did not meet the same problem in older systemd, not
sure if later systemd has any changes that makes the issue "Assess
denied" happens for LDAP, or could you please let me know it is a
expected behavior for every version of systemd?

Thanks,
Brs,
Naruto

On Fri, Mar 8, 2019 at 4:59 PM Mantas Mikulėnas <grawity at gmail.com> wrote:
>
> On Fri, Mar 8, 2019 at 11:54 AM Lennart Poettering <lennart at poettering.net> wrote:
>>
>> On Fr, 08.03.19 16:05, Bao Nguyen (baondt at gmail.com) wrote:
>>
>> > Hi Lennart,
>> >
>> > After debugging the problem, when strace the busctl call method command
>> >
>> > strace -f -tt busctl call org.freedesktop.systemd1
>> > /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager GetUnit s
>> > sys-devices-platform-serial8250-tty-ttyS6.device
>> >
>> >
>> > 07:54:32.027830 connect(3, {sa_family=AF_LOCAL,
>> > sun_path="/var/run/dbus/system_bus_socket"}, 33) = 0
>> > 07:54:32.028045 getsockopt(3, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0,
>> > gid=0}, [12]) = 0
>> > 07:54:32.028146 fstat(3, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
>> > 07:54:32.028240 getsockopt(3, SOL_SOCKET, SO_ACCEPTCONN, [0], [4]) = 0
>> > 07:54:32.028369 getsockname(3, {sa_family=AF_LOCAL, NULL}, [2]) = 0
>> > 07:54:32.028477 geteuid()               = 701
>> > 07:54:32.028584 sendmsg(3, {msg_name(0)=NULL, msg_iov(3)=[{"\0AUTH EXTERNAL
>> > ", 15}, {"373031", 6}, {"\r\nNEGOTIATE_UNIX_FD\r\nBEGIN\r\n", 28}],
>> > msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 49
>> > 07:54:32.028854 gettid()                = 6861
>> > 07:54:32.028954 getrandom("f\7Wa\3512\306\316\3325\246\372\207\247\272(",
>> > 16, GRND_NONBLOCK) = 16
>> > *07:54:32.029115 recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"REJECTED
>> > EXTERNAL DBUS_COOKIE_SH"..., 256}], msg_controllen=0,
>> > msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) =
>> > 82*
>> > *07:54:32.029230 writev(2, [{"Access denied", 13}, {"\n", 1}], 2Access
>> > denied*
>> >
>> > I can see that the "Access Denied" is thrown because the system dbus fail
>> > to authenticate  NEGOTIATE_UNIX_FD sent from client . It returns   *REJECTED
>> > EXTERNAL DBUS_COOKIE_SH. * Could you please help to explain more why DBUS
>> > fail to authenticate? Is there any work around to make it authenticate
>> > successfully? I restart dbus and the error is gone away. Not sure why and
>> > maybe restarting dbus is not a good WA to do.
>> >
>> > My system uses SSSD, PAM and LDAP to authenticate the user,
>>
>> dbus-daemon resolves users mentioned in its policy files at
>> start-up. Are you referencing users that are defined in SSSD/LDAP? If
>> so, that's most likely your problem. You can't do that.
>>
>> dbus policy can only reference users that are available locally at any
>> time, i.e. generally system users, not human users.
>>
>
> Hmm, but in this case, the client seems to be completely refused access to the bus – not just blocked by policy from sending some message. The system bus normally allows any user to connect (I mean, I have no problems accessing it from an LDAP account), so I'm not sure why the bus config should matter at this point.
>
> --
> Mantas Mikulėnas