Re: root is unable to open display

[Tom H]

On Sun, Sep 6, 2015 at 10:04 AM, Nico Kadel-Garcia  wrote:
> On Sun, Sep 6, 2015 at 6:51 AM, Tom H  wrote:
>> On Sat, Sep 5, 2015 at 10:42 AM, Nico Kadel-Garcia  wrote:
>>> On Sat, Sep 5, 2015 at 4:52 AM, Tom H  wrote:

 systemd introduced "machinectl shell localhost" in systemd 225 that
 essentially does the same as "ssh localhost" from an env perspective.

 Since it's being rebased to 219 for SL 7.2, perhaps that command'll be
 included in SL 7.4 with a systemd 22x (or it might be backported at
 some point...).
>>>
>>> systemd's tendency to find a particular issue with a known, stable
>>> toolkit and then bolt it onto systemd is scaring the tar out of me.
>>> Attempting to replace su or sudo seems to be yet another example of
>>> this. The subject has been discussed, heatedly, in the Fedora mailing
>>> list.
>>
>> AFAIR there was a systemd-devel@ thread and various bug reports about
>> people having a problem with su/sudo when using them to launch X apps
>> because XDG_RUNTIME_DIR was the su-ing/sudo-ing user's and perms of
>> XDG_RUNTIME_DIR or of its contents were being changed to root because
>> that directory couldn't be changed within a session.
>>
>> So the problem's that su doesn't create a new login session but su was
>> never intended for this. Its man page even says "The su command is
>> used to become another user during a login session".
>
> Right. "su" doesn't. "sudo" can, by setting /etc/sudoers or
> /etc/sudoers.d options.

I don't think that sudo can create a new session where "session"
corresponds to the consolekit/logind meaning, but I'd have to read
"man sudoers" to be sure.

Re: root is unable to open display

[Nico Kadel-Garcia]

On Sun, Sep 6, 2015 at 6:51 AM, Tom H  wrote:
> On Sat, Sep 5, 2015 at 10:42 AM, Nico Kadel-Garcia  wrote:
>> On Sat, Sep 5, 2015 at 4:52 AM, Tom H  wrote:
>
>
>>> systemd introduced "machinectl shell localhost" in systemd 225 that
>>> essentially does the same as "ssh localhost" from an env perspective.
>>>
>>> Since it's being rebased to 219 for SL 7.2, perhaps that command'll be
>>> included in SL 7.4 with a systemd 22x (or it might be backported at
>>> some point...).
>>
>> systemd's tendency to find a particular issue with a known, stable
>> toolkit and then bolt it onto systemd is scaring the tar out of me.
>> Attempting to replace su or sudo seems to be yet another example of
>> this. The subject has been discussed, heatedly, in the Fedora mailing
>> list.
>
> AFAIR there was a systemd-devel@ thread and various bug reports about
> people having a problem with su/sudo when using them to launch X apps
> because XDG_RUNTIME_DIR was the su-ing/sudo-ing user's and perms of
> XDG_RUNTIME_DIR or of its contents were being changed to root because
> that directory couldn't be changed within a session.
>
> So the problem's that su doesn't create a new login session but su was
> never intended for this. Its man page even says "The su command is
> used to become another user during a login session".

Right. "su" doesn't. "sudo" can, by setting /etc/sudoers or
/etc/sudoers.d options.

> Lennart P offered to change the behavior of "su -l" and "sudo -i" via
> a pam argument to create a new session. I don't remember anyone
> writing a patch to put this change into motion and I assume that
> distros have been working around the problem for launching their
> various DEs' system-settings apps.

There are various approaches. They relied on using small, known,
tested tools and worked *within* those tools to leverage the desired
behavior.

> I don't know why the pam patch never materialized but, more or less
> two years later, using machinectl to switch users must've seemed
> natural. AFAIUI it looks like a login to localhost-as-a-container.

Yeah. The problem is that it's adding a systemd only compatible tool,
which means Linux only, to create Yet Another Root Access Tool(tm).

> But the change was introduced with an "su is broken" meme when it
> would've been more accurate to say "using su as gksu is broken" or
> "using su to launch an X app is broken" because using su/sudo at the
> command line's fine. systemd upstream must like to shoot itself in the
> foot communication-wise.

Yeah.

>> I'm afraid that su replacement looks like a Linux-only major security
>> problem begging to happen.
>
> There's "doas" in openbsd so "we" aren't the only ones with an OS-specific 
> tool.

I've not been running OpenBSD for some time, but I believe you. That
one actually looks interesting, and I'd have more confidence in it
with its very small and limited behavior than I would with integrating
"su" like behavior into the growing Sargasso Sea of accumulated debris
that is systemd.

Re: root is unable to open display

[Tom H]

On Thu, Aug 27, 2015 at 12:29 PM, Nico Kadel-Garcia nka...@gmail.com wrote:
 On Thu, Aug 27, 2015 at 9:08 AM, Tom H tomh0...@gmail.com wrote:
 On Mon, Aug 24, 2015 at 6:54 PM, ToddAndMargo toddandma...@zoho.com wrote:

 I can run anything as a regular user but not my apps
 as root.  I am sure a reboot will fix this, but
 is there a way to fix this without rebooting?

 This started after I fired up two VM's in KVM

 # leafpad smb.conf 
 [1] 16905
 [root@localhost samba]# No protocol specified
 leafpad: Cannot open display:

 # echo $DISPLAY
 :0.0

 You need to specify XAUTHORITY=

 Doing a sudo or su to run things as the root user can also clear
 your individual user X settings, as can using ssh to access the local
 system as a root user if you do not allow X forwarding.

Whether using su or sudo, you can set DISPLAY and XAUTHORITY to those
of the user from whom you're switching.

I don't use root with GUI apps so this is theoretical knowledge.

You could set up a polkit action/policy (mimicking
/usr/share/polkit-1/actions/com.ubuntu.update-notifier.policy on my
laptop running Ubuntu):

policyconfig
  action id=com.todd.pkexec.leafpad
messageAuthentication is required to run leafpad as root/message
icon_nameleafpad/icon_name
defaults
  allow_anyno/allow_any
  allow_inactiveno/allow_inactive
  allow_activeauth_admin/allow_active
/defaults
annotate 
key=org.freedesktop.policykit.exec.path/usr/bin/leafpad/annotate
annotate key=org.freedesktop.policykit.exec.allow_guitrue/annotate
  /action
/policyconfig

And you'll then be able to run (as a member of wheel) pkexec leafpad .

Re: root is unable to open display

[Tom H]

On Mon, Aug 24, 2015 at 6:54 PM, ToddAndMargo toddandma...@zoho.com wrote:

 I can run anything as a regular user but not my apps
 as root.  I am sure a reboot will fix this, but
 is there a way to fix this without rebooting?

 This started after I fired up two VM's in KVM

 # leafpad smb.conf 
 [1] 16905
 [root@localhost samba]# No protocol specified
 leafpad: Cannot open display:

 # echo $DISPLAY
 :0.0

You need to specify XAUTHORITY=