RE: [suse-linux-uk-schools] wont run as root
![](https://seccdn.libravatar.org/avatar/022d8940171e25a8319053be27a247b9.jpg?s=120&d=mm&r=g)
Comments interspersed ...
--- E Lea <ed@centralmanclc.com> wrote:
It's often easier, as the user who started the X server to run
xhost + localhost
This isn't as secure, but as long as you trust all local users is fine.
You also have to issue the following further command after you've su'd to the other user ID (remembering that we were all trying to help you run an application as root while being logged in as a.n.other: export DISPLAY=localhost:0.0 Then, and only then can you type the command you wish to execute.
Hmm, I prefer these options: 4)
$ su - # export DISPLAY=:0.0 # xauth merge ~n6tadam/.Xauthority
where "~n6tadam" is the user X is running as. Personally number 4) is much more secure. Never use number 1) unless you're mad.
I agree with Thomas's assessment of risk and his is a fair alternative to my original suggestion, but I would venture to suggest that using secure sockets (ssh) offers equally reliable connection security, and with a minimum of command-line fuss. Interestingly, my suggestion still failed at a later stage in the application execution, and the one that worked was the (in this case) far simpler expedient of logging in as the root user from the xdm/kdm/gdm login. I'm pretty sure that the other solutions offering a borrowed ID of root during a non-root login would also have failed at the same point. Given that, in this particular case, the 'borrowed ID' solution was a dismal failure, I should still claim that a further advantage of the ssh solution is that it is also easy to implement across network comms quite securely. (I regularly use this one: ssh -X root@foreign.host yast2 to manage resources on remote stations on the network.) I have also in the past used Thomas's 'magic-cookie' solution, but it proves more tricky than the one I favour. Now shoot me down! Andrew -- Email: aray@computerpark.co.uk -- Email: aray@computerpark.co.uk --------------------------------------------------------- This private and confidential e-mail has been sent to you by Computer Park Ltd. If you are not the intended recipient of this e-mail and have received it in error, please notify us via the email address or telephone number below, and then delete it from your mailbox. Email: mailbox@computerpark.co.uk Tel: +44 (0) 1536 417155 Fax: +44 (0) 1536 417566 Head Office: Computer Park Ltd, Broughton Grange, Headlands, Kettering Northamptonshire NN15 6XA Registered in England: 3022961. Registered Office: 6 North Street, Oundle, Peterborough PE8 4AL =========================================================
![](https://seccdn.libravatar.org/avatar/7e5ee5cb96dff0071c7c6c07567f23a7.jpg?s=120&d=mm&r=g)
--- Andrew RAY <aray@computerpark.co.uk> wrote:
Comments interspersed ...
All e-mails should be answered like this -- top-posting is a pain :)
--- E Lea <ed@centralmanclc.com> wrote:
It's often easier, as the user who started the X server to run
xhost + localhost
This isn't as secure, but as long as you trust all local users is fine.
You also have to issue the following further command after you've su'd to the other user ID (remembering that we were all trying to help you run an application as root while being logged in as a.n.other:
export DISPLAY=localhost:0.0
This may/may not work depending on how things are setup. Indeed, exporting DISPLAY is not enough on my debian system.
Then, and only then can you type the command you wish to execute.
Hmm, I prefer these options: 4)
$ su - # export DISPLAY=:0.0 # xauth merge ~n6tadam/.Xauthority
where "~n6tadam" is the user X is running as. Personally number 4) is much more secure. Never use number 1) unless you're mad.
I agree with Thomas's assessment of risk and his is a fair alternative to my original suggestion, but I would venture to suggest that using secure sockets (ssh) offers equally reliable connection security, and with a minimum of command-line fuss.
I disagree there -- it would almost certainly create a bigger overhead on the system. I'd recommend it perhaps to those of you that have to administer the machine from a distance, but if it is on a local box, I'd go with one of the altenatives already discussed. One trick I use (for remote systems) is: X -query <IP> trick on my server so that I can connect locally to it.
Interestingly, my suggestion still failed at a later stage in the application execution, and the one that worked was the (in this case) far simpler expedient of logging in as the root user from the xdm/kdm/gdm login. I'm pretty sure that the other solutions offering a borrowed ID of root during a non-root login would also have failed at the same point.
You neglect to say *what* failed, and how. I'd be interested in this.
Given that, in this particular case, the 'borrowed ID' solution was a dismal failure, I should still claim that a further advantage of the ssh solution is that it is also easy to implement across network comms quite securely. (I regularly use this one:
ssh -X root@foreign.host yast2
to manage resources on remote stations on the network.) I have also in the past used Thomas's 'magic-cookie' solution, but it proves more tricky than the one I favour.
How's that? If you don't like xauth (grin), the "sudo" is an even simpler means, in my opinion.
Now shoot me down!
Nah, I can see that you and I might get along just fine without shooting eachother :) -- Thomas Adam ===== Thomas Adam "The Linux Weekend Mechanic" -- www.linuxgazette.com ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk
participants (2)
-
Andrew RAY
-
Thomas Adam