Since we had much success (performance improvements) by moving the
"corporate server apps" to Linux, the eyes now turn to the "user GUI",
which happens to be very network intensive and even more CPU
intensive. This is not your typical "forms application". This is a app
that uses the computer a lot.

Anyway. Thinking about how to deploy it, I think that it would be
cleaner if the apps were running under a userid different from the
user's own userid.

This way, the user would have his own ****, whatever he wants, and our
corporate apps would live under a separate account and be managed by
our scripts, cron jobs etc, which the user cannot fsck up even if he
wanted to.

The catch, of course, is that these are GUI apps and would run on the
user's desktop, but under the effective user id of the separate
management account, not the user.

The user would have an icon that he could click to bring up the app,
or maybe it would be autostarted from the management account's
crontab.

To get this to work, some sort of magic would need to be done with
"xauth" or some such, does anyone know how to get user A to open a
window on a terminal owned by user B?

Speed is of the essence and using ssh -Y is out of question.
--
Due to extreme spam originating from Google Groups, and their inattention
to spammers, I and many others block all articles originating
from Google Groups. If you want your postings to be seen by
more readers you will need to find a different means of
posting on Usenet.
http://improve-usenet.org/

On Mon, 04 Aug 2008 16:18:17 -0500, Ignoramus22807 wrote:

> To get this to work, some sort of magic would need to be done with
> "xauth" or some such, does anyone know how to get user A to open a
> window on a terminal owned by user B?
>
> Speed is of the essence and using ssh -Y is out of question.

http://ubuntuforums.org/archive/index.php/t-266443.html

Scroll down to mlind's comment. The users can be regular, not root.
Remember to do a "chmod +r /tmp/display" so userb can read the file.

Maybe usera should also do a "shred -u /tmp/display" after userb has
xauth merged the cookie.

And I did try first, "xhost +userb@$HOSTNAME" which was accepted but
did not yield the ability for userb to run an X app.

--
// This is my opinion.

["Followup-To:" header set to alt.os.linux.ubuntu.]
On Mon, 04 Aug 2008 16:18:17 -0500,
Ignoramus22807 wrote:
> Since we had much success (performance improvements) by moving the
> "corporate server apps" to Linux, the eyes now turn to the "user GUI",
> which happens to be very network intensive and even more CPU
> intensive. This is not your typical "forms application". This is a app
> that uses the computer a lot.
>
> Anyway. Thinking about how to deploy it, I think that it would be
> cleaner if the apps were running under a userid different from the
> user's own userid.

I'm not sure what you mean by cleaner.

> This way, the user would have his own ****, whatever he wants, and our
> corporate apps would live under a separate account and be managed by
> our scripts, cron jobs etc, which the user cannot fsck up even if he
> wanted to.

This could also be done by storing all data and config files where the
local user is unable to write to them. If you have the source
available for the program(s), you can ignore user config files and
rely on system config files for the app(s) by patching the software.

> The catch, of course, is that these are GUI apps and would run on the
> user's desktop, but under the effective user id of the separate
> management account, not the user.

So you want to create a security problem? If you run a program as a
different user, everything that program does is done as that user.

> The user would have an icon that he could click to bring up the app,
> or maybe it would be autostarted from the management account's
> crontab.
>
> To get this to work, some sort of magic would need to be done with
> "xauth" or some such, does anyone know how to get user A to open a
> window on a terminal owned by user B?
>
> Speed is of the essence and using ssh -Y is out of question.

Good luck, but I think you're barking up the wrong tree.

JMTC,

Michael C.
--
mjchappell@verizon.net http://mcsuper5.freeshell.org/

To hell with circumstances; I create opportunities. - Bruce Lee

On Mon, 04 Aug 2008 16:18:17 -0500, Ignoramus22807 wrote:

> To get this to work, some sort of magic would need to be done with
> "xauth" or some such, does anyone know how to get user A to open a
> window on a terminal owned by user B?

sux


--
A Freudian slip is when you say one thing but mean your mother.

In newsan.2008.08.05.07.00.05.30012@besty.org.uk,
Trevor Best typed:

>> To get this to work, some sort of magic would need to be done with
>> "xauth" or some such, does anyone know how to get user A to open a
>> window on a terminal owned by user B?
>
> sux

It sure does. Better to rewrite the app. to include the necessary security
measures.

In alt.os.linux.ubuntu h.stroph wrote:
> In newsan.2008.08.05.07.00.05.30012@besty.org.uk,
> Trevor Best typed:

> >> To get this to work, some sort of magic would need to be done with
> >> "xauth" or some such, does anyone know how to get user A to open a
> >> window on a terminal owned by user B?
> >
> > sux

> It sure does. Better to rewrite the app. to include the necessary security
> measures.

*huh* Nice one.

$ apt-cache search sux
sux - wrapper around su which will transfer your X credentials

--
Niklaus

In comp.os.linux.misc Ignoramus22807 wrote:
> Anyway. Thinking about how to deploy it, I think that it would be
> cleaner if the apps were running under a userid different from the
> user's own userid.

The application executable files should belong to root. This way they
are not use modifiable, and the root account is the currently the only
account that is protected by "squashing" over a network file system.

Applications running as root, can drop their privileges to any account
name, and permissions can be configured to allow only certains users to
be able to start and stop them.

I think you need to study users and groups again. You can achieve what
you desire using these mechanisms, I am certain.

Regards,

Mark.

--
Mark Hobley,
393 Quinton Road West,
Quinton, BIRMINGHAM.
B32 1QE.

On Tue, 05 Aug 2008 09:43:23 +0000, Niklaus Kuehnis wrote:

> $ apt-cache search sux
> sux - wrapper around su which will transfer your X credentials

That should be better than:

1) "xauth extract"
2) scp to taarget user
3) "xauth merge"

--
// This is my opinion.