Fw: [PATCH] GPM 1.20.0 fix for non-root users with devfs

DJ Lucas dj_me at swbell.net
Fri Aug 16 18:03:12 PDT 2002


Don't know if ya'll seen this on lfs-support, but sounds good to include
it...I don't use devfs so no matter to me, but if it don't hurt normal
/dev users, maybe it should be included.  perhaps this should be sent to
the maintainer??? only a one liner.


"Bruce J.A. Nourish" wrote:
> * Note: I'm not sure if anyone else has found a fix for this. I find
it
> * had to believe that such a serious bug has existed for such a long
> * time without bieng fixed; but this seems to be the case. Regardless,
> * this is my contribution. If one of the BLFS people wants to include
> * this in BLFS, please do; an attribution would be appreciated in that
> * case. -- BJAN
>
> Problem: Non-root GPM clients cause an error message upon opening a
> connection to the GPM daemon. Most will function anyway, but with no
> GPM support (except in the general sense). The syslog message is
> usually, "Failed GPM connection attempt for UID nnnn on VC 0". I have
> seen messages in the archives about this, although I never saw a fix,
> and one isn't mentioned in BLFS, AFAIK. Also, if you suspend (^Z) a
> client compiled against a buggy GPM and then start another GPM client,
> the second client will hang until killed.
>
> Quick fix: Go into src in your GPM source directory, (e.g
> /usr/src/gpm-1.20.0/src) and apply the following patch[1].
> As there's not need to reinstall the GPM docs, you can then run make
&&
> make install from src. NOTE: If you're using a dynamically linked bash
> that uses ncurses, and your ncurses is compiled with GPM support, the
> shell will probably segfault (mine did). Don't panic. Login again and
> run ldconfig. Note that any GPM clients that use the static GPM
library
> will need to be recompiled. [2]
>
> Analysis: When a user logs in on a virtual console (e.g. vc/1), that
> console is chown'd to them. This prevents people from casually reading
> and writing to each-other's consoles. For the same reason, when a GPM
> client tries to connect to the daemon, GPM checks the ownership of the
> connecting processes' tty. If the tty ownership and the process
> ownership do not match, GPM refuses the connection as bogus.
> The GPM client tells the daemon what tty it is on by looking at the
last
> character of the name of the current tty, as given by ttyname(3).
> liblow.c does this with the following code:
>
>   conn->vc=atoi(&tty[strlen(consolename)]);
>
> Experienced C programmers (and quite _inexperienced_ C programmers)
will
> soon see the problem. All strings in C are null terminated, that is,
> they have an extra digit, of value NULL on the end. Thus the above
> command passes the value \0 into the atoi(3) function. This faithfully
> yields the integer 0, which is then stored in conn->vc, the structure
by
> which the GPM client lib communicates it's connection request to the
GPM
> daemon. In other words, the GPM client will always request a
connection
> on vc/0 (tty0). On linux, tty0 is a special device that always referrs
> to the the controlling tty of the current process. It is a handy
> shortcut for write operations; but it always belongs to root. Thus a
> non-root connection to GPM will always fail.
>
> Hacking notes: I would be interested to hear from anyone using olde
> style /dev entries whether they had this problem. You can test it
> without breaking anything by applying the patch and running make mev.
> Then run the new mev as a non-root user and see if it works. No need
to
> change anything else (mev uses libgpm.a in the current directory). The
> whole GPM codebase is a clusterf*ck. Look at the malloc() on line 246
of
> liblow.c for an example.
>
> [1] If you're lost, just save this message somewhere and then, while
in
> the GPM/src directory, do:
>
> # patch < /path/to/this.message
>
> patch will figure out what to do with it.
>
> [2] The readelf(1) command can be used to figure out whether a program
> linked against the dynamic GPM library. By implication, if it did so,
it
> did not link against the static library. To see which libraries an ELF
> program is linked against, type:
>
> $ readelf -d /path/to/app | grep NEEDED
>
> This is the output of the above, when applied to my elinks binary:
>
>  0x00000001 (NEEDED)                     Shared library: [libX11.so.6]
>  0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
>  0x00000001 (NEEDED)                     Shared library:
[libbz2.so.1.0]
>  0x00000001 (NEEDED)   /* Note --> */    Shared library: [libgpm.so.1]
>  0x00000001 (NEEDED)                     Shared library: [libc.so.6]
>
>
patch below unquoted

Thanks,

DJ
____________________________________________________________


--- liblow.c.old 2002-08-16 11:34:47.000000000 -0700
+++ liblow.c 2002-08-16 11:34:52.000000000 -0700
@@ -262,7 +262,7 @@
            goto err;
          }

-         conn->vc=atoi(&tty[strlen(consolename)]);
+         conn->vc=atoi(&tty[strlen(consolename)-1]);
       }

       if (gpm_consolefd == -1)

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-dev' in the subject header of the message



More information about the blfs-dev mailing list