[gpm]Re: gpm 1.19.4 X Raw Hide version

[Nico Schottelius]

> > About gpm-1.19.3-root.patch:
> >
> > -       $(INSTALL_PROGRAM) -o root -m 755 disable-paste $(bindir)/disable-paste
> > +       $(INSTALL_PROGRAM) disable-paste $(bindir)/disable-paste
> >
> > I think Red Hat removed -o root -m 755 because it's the
> > default.
>
> Mainly because we don't build RPMs as a root user for security concerns
> (everything should be buildable as non-root), and this breaks that.

Do you use install as non root user ? That's interesting.
I would have problems if I do that.

> > > >    gpm-1.19.2-limits.patchName: gpm-1.19.2-limits.patch
> > > >                           Type: Plain Text (text/plain)
> > >
> > > OPEN_MAX is defined in linux/limits.h.
> > > So we can use it. Short: refused/already applied.
>
> Yes, but OPEN_MAX is a poor fallback from the actual value obtained from
> the sysconf() system call.  The summary says it all:
>
> SYSCONF(3)          Linux Programmer's Manual          SYSCONF(3)
>
> NAME
>        sysconf - Get configuration information at runtime
>
> It is also POSIX compliant.  And OPEN_MAX has fluctuated through glibc
> 2.x's development in its presence.

Maybe it will be removed later, when gpm_report() is present.

> > > >    gpm-1.19.3-devfs.patchName: gpm-1.19.3-devfs.patch
> > > >                          Type: Plain Text (text/plain)
> > >
> > > refused. why shouldn't we use /dev/console ? It still exists in devfs.
> > > the #if 1 is removed in the next release.
>
> We found that some devfs kernels didn't have a /dev/console during testing
> back in January, and thus made this patch.  The situation may or may not
> have changed.

it changed. I am only running devfs on all machines i have.

> > > >    gpm-1.19.3-noworldwrite.patchName: gpm-1.19.3-noworldwrite.patch
> > > >                                 Type: Plain Text (text/plain)
> > >
> > > nothing applied. parts where also senseless:
> > >
> > > +      unlink(tmp_pidfile);
> > >
> > > unlink the pidfile of another running gpm!
> > > refused.
>
> Hmm.  OK, so you are going to leave use of mktemp, a known insecure
> function, which has caused countless security issues?  The unlink fixes a
> problem associated with the security fix. See RPM changelog, and trust
> use, we dealt with this patch with other vendors on our security lists.

I didn't leave mktemp. It's changed to mkstemp.
My comment was wrong. Have a look into gpm-1.19.6's sources
if you want to see what actually changed.


> > > >    gpm-1.19.3-serialconsole.patchName: gpm-1.19.3-serialconsole.patch
> > > >                                  Type: Plain Text (text/plain)
> > >
> > > I don't know much about serialconsole.
> > > Do we really need so much code for the serial
> > > console ? Where's the matter with the normal code ?
> > > delayed until someone helps me with serialconsole (maybe you ?).
>
> From Red Hat bug report #15784:
>
> "If gpm RPM is installed, gpm attempts to run
> on /dev/console rather than on /dev/tty0.

the problem is, there have been /still are some hard coded
ttys.

> If console is serial with a kernel option,
> gpm prints garbage to the console and loops."

That's not good :)

1.) But if I understood it right, the problem is the following:
If there is a serial console we may not write on it the normal way.
--> either we should ignore it
--> or we need to write to it in a way it's usable.

My question to you, what do we have to do different ?
Why can't we write to the serial console like to any another
file ?

2.) comment to the patch :

If I understood it correct, we oops() when we got
a serial console. That's not a good behaviour.
It should still be possible to use gpm!
Preston, we should talk about the new report()
funtion in another mail. Things like serial console
can be implemented in it.


> So we fixed it.  Yes, you need that much code to detect presence of a
> serial console.

:)
Okay, accepted. But I don't like the way it's implemented.

Nico