This is the "never release a security fix in a hurry" release. The
security fixes in modutils 2.3.20 had some side effects on some config
files. Linus knocked back environment variable MOD_SAFEMODE, instead
the kernel propagates the real uid that caused modprobe to be invoked.
ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/modutils/v2.3
patch-modutils-2.3.21.bz2 Patch from modutils 2.3.20 to 2.3.21
modutils-2.3.21.tar.bz2 Source tarball, includes RPM spec file
modutils-2.3.21-1.src.rpm As above, in SRPM format
modutils-2.3.21-1.i386.rpm Compiled with egcs-2.91.66, glibc 2.1.2
modutils-2.3.21-1.sparc.rpm Compiled for combined sparc 32/64
Changelog extract
* Remove compile warnings in xstrcat.
* snprintf cleanups.
* Set safemode when uid != euid.
* Strip quotes from shell responses.
On Wed, Nov 22, 2000 at 11:25:17PM +1100, Keith Owens wrote:
> This is the "never release a security fix in a hurry" release. The
> security fixes in modutils 2.3.20 had some side effects on some config
> files. Linus knocked back environment variable MOD_SAFEMODE, instead
> the kernel propagates the real uid that caused modprobe to be invoked.
>
> ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/modutils/v2.3
>
> patch-modutils-2.3.21.bz2 Patch from modutils 2.3.20 to 2.3.21
> modutils-2.3.21.tar.bz2 Source tarball, includes RPM spec file
> modutils-2.3.21-1.src.rpm As above, in SRPM format
> modutils-2.3.21-1.i386.rpm Compiled with egcs-2.91.66, glibc 2.1.2
> modutils-2.3.21-1.sparc.rpm Compiled for combined sparc 32/64
>
> Changelog extract
>
> * Remove compile warnings in xstrcat.
> * snprintf cleanups.
> * Set safemode when uid != euid.
> * Strip quotes from shell responses.
+ add RedHat ism's with a --rhc (red hat compatible) -i -m (-F)
RedHat kind of is the standard in the commercial world in the US.
:-)
Jeff
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
On Wed, 22 Nov 2000, Jeff V. Merkey wrote:
> + add RedHat ism's with a --rhc (red hat compatible) -i -m (-F)
>
> RedHat kind of is the standard in the commercial world in the US.
Regardless of the bogus nature of this statement, boss.
GNU/OS packages are to be modified locally and a generic form that does
not have flavor or spin is what maintainers release.
Regards,
Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development
On Wed, Nov 22, 2000 at 10:19:17AM -0800, Andre Hedrick wrote:
> On Wed, 22 Nov 2000, Jeff V. Merkey wrote:
>
> > + add RedHat ism's with a --rhc (red hat compatible) -i -m (-F)
> >
> > RedHat kind of is the standard in the commercial world in the US.
>
> Regardless of the bogus nature of this statement, boss.
> GNU/OS packages are to be modified locally and a generic form that does
> not have flavor or spin is what maintainers release.
>
> Regards,
The -m option is a good idea. Strange since most of the commercial
releases implement these additions. I just hope Keith has a good
sense of humor.
:-)
Jeff
>
> Andre Hedrick
> CTO Timpanogas Research Group
> EVP Linux Development, TRG
> Linux ATA Development
> > * Remove compile warnings in xstrcat.
> > * snprintf cleanups.
> > * Set safemode when uid != euid.
> > * Strip quotes from shell responses.
> + add RedHat ism's with a --rhc (red hat compatible) -i -m (-F)
>
> RedHat kind of is the standard in the commercial world in the US.
I don't think it's necessary or appropriate to taylor things for a particular
distribution even if it may unfortunately be 'standard' for some people.
-d
On Wed, 22 Nov 2000, David Ford wrote:
> > > * Remove compile warnings in xstrcat.
> > > * snprintf cleanups.
> > > * Set safemode when uid != euid.
> > > * Strip quotes from shell responses.
> > + add RedHat ism's with a --rhc (red hat compatible) -i -m (-F)
> >
> > RedHat kind of is the standard in the commercial world in the US.
>
> I don't think it's necessary or appropriate to taylor things for a particular
> distribution even if it may unfortunately be 'standard' for some people.
Zackerly. My system will certainly look like a RedHat system; it's
based on one. However (particularly with regards to kernels and
modules), I can almost guarantee it won't react like a RedHat system.