Re: X authentication and su (Re: changing framebuffer device owner during login)
On Sat, 30 Jun 2001, Matt Zimmerman wrote:
> On Sat, Jun 30, 2001 at 02:57:51PM -0400, Matt Zimmerman wrote:
>
> > On Sat, Jun 30, 2001 at 01:52:42AM -0700, Francois Gouget wrote:
> >
> > > It's not very useful if you don't have X. And making a package for just
> > > one 8KB file seems a bit over the top. Ok, with the man page that would
> > > be to files, and it would be a step towards the 10000 packages but
> > > still... So I would prefer if there was an existing package where it
> > > would fit nicely.
> >
> > Perhaps where it would fit most nicely would be in the form of a patch to
> > su(1). It could still work using a pipe to xauth, so it wouldn't have to be
> > linked against the X libraries. You also wouldn't have to do that awful bit
> > with the TERM environment variable.
>
> I worked out a patch for this, but it seems that xauth inexplicably refuses to
> write the generated key to standard output, rather than a file. It seems to do
> OK with extract/merge/source, but not generate. I don't think it's appropriate
> for a program like su to require use of a temporary file, and I don't want to
> introduce a dependency on X by using the library routines. Does anyone know
> how to gen xauth to cooperate, or am I stuck using a temporary file?
Initially I also thought su would be the best place for this but I've
changed my mind since then.
* su would have to invoke xauth and read from the pipe... all while it
is still root. That seems pretty dangerous. The reason why I say it has
to do it while being root is that once you changed the id to that of the
other user you cannot access the original user's .Xauthority file
anymore.
* I that respect, having a sux version written in C that would use the
X API to transfer the cookies would seem safer.
* Even if su does not depend on the X libraries being installed to run,
having it use X tools would bother me.
* I don't think options like --untrusted or --timeout belong to su.
(initially I thought 'su -X' would simply copy the .Xauthority file,
but then I realized this not the right way)
Note also that you can fix the TERM issue more simply: all that's
needed is a switch to preserve a specific environment variable. Then sux
would do 'su -p sux_xauth_data $su_opts ... env --unset=sux_xauth_data'.
But I don't think the dirty tricks I play with TERM would cause any
problem. The main weakness of sux is the handling of spaces and
double-quotes in the command to run (not that I expect this to be used
much anyway). This item can easily be fixed in a perl version... but
then you introduce a dependency on perl :-/. A C version would work too,
but I'm not overly enthusiastic about doing all the piping in C.
--
Francois Gouget fgouget@free.fr http://fgouget.free.fr/
La terre est une bêta...
Reply to: