Re: What does this mean??

Steve wrote:

> Trying to install a package that came as a shell script, but when i
do "sh
> install-crossover-standard-demo-4.2.sh" i get a message that says
"Setup
> requires an X display to run. There is a display variable set,
however
> you have no permissions to access the X server (:0.0) it points to.> Try running xhost +localhost before su'ing to root."
>
> Hope someone can help.
Steve,

Due to heightened security on SuSE and X you cannot run an X session
as a
normal user, SU to root and run some process that wants to output to
X,
even if the DISPLAY environment is set. I also have issues with the
xhost
in this configuration.

Solution:

What I do is use the following command as a normal user:
ssh root@localhost -X

This command starts a ssh session (must have the sshd deamon running)
to the
local machine, logging you in as root. The important bit is the -X
(must be
capital). This redirects the output of the X session through the ssh
session.

To log out of the ssh session, when finished. Ctrl+D.

HTH
Jim

--
Pye, James Pye, chmod 007
The Ultimate Open Source

On Tue, 07 Jun 2005 21:41:23 GMT
Jim Pye <jtpye@[remove-this]attglobal.net> wrote:

> Due to heightened security on SuSE and X you cannot run an X session

> as a normal user, SU to root and run some process that wants to
> output to X, even if the DISPLAY environment is set. I also have
> issues with the xhost in this configuration.
>
> Solution:
>
> What I do is use the following command as a normal user:
> ssh root@localhost -X
>
> This command starts a ssh session (must have the sshd deamon
running)
> to the local machine, logging you in as root. The important bit is
> the -X (must be capital). This redirects the output of the X session

> through the ssh session.
>
> To log out of the ssh session, when finished. Ctrl+D.
>

It's a *whole* lot easier to do:

sux
(enter root password)

;-)


--
Kevin Nathan (Arizona, USA)
Linux Potpourri and a.o.l.s. FAQ -- http://www.project54.com/linux/

Open standards. Open source. Open minds.
The command line is the front line.
Linux 2.6.8-24.14-default
3:33pm up 8 days 20:36, 9 users, load average: 0.20, 0.16, 0.21

Kevin Nathan wrote:

> On Tue, 07 Jun 2005 21:41:23 GMT
> Jim Pye <jtpye@[remove-this]attglobal.net> wrote:
>
>> Due to heightened security on SuSE and X you cannot run an X
session
>> as a normal user, SU to root and run some process that wants to
>> output to X, even if the DISPLAY environment is set. I also have
>> issues with the xhost in this configuration.
>>
>> Solution:
>>
>> What I do is use the following command as a normal user:
>> ssh root@localhost -X
>>
>> This command starts a ssh session (must have the sshd deamon
running)
>> to the local machine, logging you in as root. The important bit is>> the -X (must be capital). This redirects the output of the X
session
>> through the ssh session.
>>
>> To log out of the ssh session, when finished. Ctrl+D.
>>
>
> It's a *whole* lot easier to do:
>
> sux
> (enter root password)
>
> ;-)
>
>

It would have been even easier if they had added a little intelligence
to su
instead of yet another command. su, sux, sudo and whatever else, sux!
There
should only be one su to rule them all.

Peter

On Wed, 08 Jun 2005 20:16:57 GMT
Peter <spamfree@tampabay.rr.com> wrote:

> It would have been even easier if they had added a little
> intelligence to su instead of yet another command. su, sux, sudo and

> whatever else, sux! There should only be one su to rule them all.

That's Windows mindset: try to make one program do everything
conceivable that anyone might want to do. 'su', 'sux' and 'sudo' are
three distinct programs because they have three distinct jobs to do.

You should not *change* 'su', a basic command on all Linux/Unix OSes.SUSE could have opted to *not* have the 'sux' command and then you can

go back to doing all the 'xhost' and setting DISPLAY and everything
else involved. Making a separate command like 'sux' *is* adding the
intelligence to 'su' without changing the normal operation of 'su'.
For
an idea of what goes on to do this, look at the 'sux' script:

less /usr/X11R6/bin/sux

Using your 'only be one su to rule them all' mindset, I can expand
that
to editors. There should only be *one* editor and it should let me
work
with it as if it was 'pico' or 'e3' or 'emacs' or 'vi' or 'kedit' or
'gedit' or 'soffice writer', etc.


--
Kevin Nathan (Arizona, USA)
Linux Potpourri and a.o.l.s. FAQ -- http://www.project54.com/linux/

Open standards. Open source. Open minds.
The command line is the front line.
Linux 2.6.8-24.14-default
2:19pm up 9 days 19:22, 9 users, load average: 0.11, 0.23, 0.43

On Wed, 08 Jun 2005 21:30:30 GMT, Kevin Nathan <knathan@project54.com>
wrote:

>Using your 'only be one su to rule them all' mindset, I can expand
that
>to editors. There should only be *one* editor and it should let me
work

I think the emacs people achieved this back in 1975 or so. ;-)

>with it as if it was 'pico' or 'e3' or 'emacs' or 'vi' or 'kedit' or>'gedit' or 'soffice writer', etc.

Actually, there's no reason that su, sudo, and sux couldn't all be the
same
program, just using different hard links to the same binary. Check out
the way
ldapadd and ldapmodify are actually the same binary, but it behaves
differently
depending on which hard link you use to load it from. vi and ed have
been doing
the same thing for at least 25 years now.

---------------------------------------------------------------------------

David Gersic
dgersic_@_niu.edu

I'm tired of receiving rubbish in my mailbox, so the E-mail address
is
munged to foil the junkmail bots. Humans will figure it out on their
own.

I agree with Kevin though that seperate is better in most cases.
There are less issues when debugging and it keeps the code lightweight

and quick versus monolithic code. Personally I'd like to see programs

that don't require running sux to make it work in the first place.

G of Borg adjusted his/her tinfoil beanie and donned asbestos
underwear
to post:

> I agree with Kevin though that seperate is better in most cases.
> There are less issues when debugging and it keeps the code
lightweight
> and quick versus monolithic code. Personally I'd like to see
programs
> that don't require running sux to make it work in the first place.

Yeah G, why have it like that? and while we are there lets do away
with
su, we can then all pretend we are running XP home, that would make it

a lot more secure.

:-)

--
Mark
Novell Support Forums SysOp
Twixt hill and high water
N. Wales, UK.
Skype <my nick> text only please

On Thu, 09 Jun 2005 16:35:48 GMT
"G of Borg" <G@ofBorg.com> wrote:

> I agree with Kevin though that seperate is better in most cases.

It's better in *all* cases where you're talking about programs or
scripts that are fairly common on the *nixes and *BSDs. Since 'sux' is

a SUSE-only script, it has no business being part of 'su'.


> There are less issues when debugging and it keeps the code
lightweight
> and quick versus monolithic code. Personally I'd like to see
programs
> that don't require running sux to make it work in the first place.
>

But, as Mark humorously pointed out, 'sux' is a security feature. It's

not the *programs* that require 'sux', it's the security of the X
server that requires you jump through hoops before letting just anyone

use your graphical screen . . . :-)


--
Kevin Nathan (Arizona, USA)
Linux Potpourri and a.o.l.s. FAQ -- http://www.project54.com/linux/

Open standards. Open source. Open minds.
The command line is the front line.
Linux 2.6.8-24.14-default
11:55am up 10 days 16:58, 9 users, load average: 0.16, 0.16, 0.10

baskitcaise wrote:

> G of Borg adjusted his/her tinfoil beanie and donned asbestos
> underwear to post:
>
> > I agree with Kevin though that seperate is better in most cases.
> > There are less issues when debugging and it keeps the code
> > lightweight and quick versus monolithic code. Personally I'd like

> > to see programs that don't require running sux to make it work in> > the first place.
>
> Yeah G, why have it like that? and while we are there lets do away> with su, we can then all pretend we are running XP home, that would> make it a lot more secure.
>
> :-)

I'm not saying do away with the security features, but perhaps designsomething that works within the application installer. You know likeyou kick off the script, it determines that it cannot proceed becauseit needs priveleges and then queries the user for permission/passwordto execute. That's what I'm getting at. It's the little things likethat which reduces the OS's accessibility to the less techinical. :-)

Kevin Nathan wrote:

> On Thu, 09 Jun 2005 16:35:48 GMT
> "G of Borg" <G@ofBorg.com> wrote:
>
> > I agree with Kevin though that seperate is better in most cases.
>
> It's better in all cases where you're talking about programs or
> scripts that are fairly common on the *nixes and *BSDs. Since 'sux'
is
> a SUSE-only script, it has no business being part of 'su'.

I didn't realise it was a SuSE only script as well. Definitely
shouldn't be incorporated!

> But, as Mark humorously pointed out, 'sux' is a security feature.
It's
> not the programs that require 'sux', it's the security of the X
> server that requires you jump through hoops before letting just
anyone
> use your graphical screen . . . :-)

Oh I agree there's a security issue, see my reply to Mark.