Skip to content

Resolve GDBus regressions in setcap/setgid programs

Simon McVittie requested to merge wip/gdbus-even-when-setcap into master

  • gdbus: Improve readability by avoiding ternary operator

  • gdbus: Rename a variable to be less misleading

    We're using "setuid" here as shorthand for any elevated privileges that should make us distrust the caller: setuid, setgid, filesystem capabilities, more obscure Linux things that set the AT_SECURE flag (such as certain AppArmor transitions), and their equivalents on other operating systems. This is fine if we do it consistently, but I'm about to add a check for whether we are literally setuid, which would be particularly confusing without a rename.

  • gdbus: Use DBUS_SESSION_BUS_ADDRESS if AT_SECURE but not setuid

    This is against my better judgement, but it's the least bad regression fix I can think of. If we don't do this, at least gnome-keyring-daemon (setcap) and msmtp (setgid) are known to regress.

    Resolves: #2305 (closed)
    Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981420
    Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981555
    Signed-off-by: Simon McVittie smcv@collabora.com

I don't like this, and if it generates CVEs later I'll be the first to say "I told you so", but it's the least bad idea I have to stop these programs from regressing.

/cc @pwithnall @stefw @dueno

Edited by Philip Withnall

Merge request reports