devil-linux-develop — developer discussions

Re: [Devil-linux-develop] [PATCH] build/scripts/scripts/save-config - security hole?

[Roland P. <pa...@ta...>]

On Tuesday 27 April 2004 06:14, Tim Tait wrote:
[...]
>
> While I'm on the topic, I think another pontential hole is the linuxrc
> script that discovers the etc.tar.bz2 file on boot... since multiple
> locations are checked, if an unpriveleged user can introduce an
> etc.tar.bz2 file onto a drive that is checked before the real one, then
> they can control the machine on the next reboot. We should check the
> file for "root" ownership and that it is not writeable by anyone else
> before loading it. Of course not being a bash master I'm not sure how to
> write that...
if you have several users on a system, the most dangerous part is rebooting. 
it's the only time a false config could be injected, but even worse: just 
pass init=/bin/bash and you have a root shell. So either: don't reboot, or: 
always attend your reboots and make sure the right config is loaded.
If you want to disable command line passing, you have to change isolinux.cfg. 
When doing that, you can also add a "config=/dev/whatever" and if you protect 
that device properly, everything should be fine.
of course, make sure no one swaps CD's and boots a rescue system...
so, IMHO, root ownership may be an additional security check, but it's 
inferior to gpg signing (but maybe we should make that part easier...)
Roland
-- 
ICQ UIN 49339118	Linux Counter #88774
GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...>

[Devil-linux-develop] Re: [Devil-linux-develop] [PATCH] build/scripts/scripts/save-config - security hole?

[Bruce S. <bw...@ar...>]

> > > While I'm on the topic, I think another pontential hole is the linuxrc 
> > > script that discovers the etc.tar.bz2 file on boot... since multiple 
> > > locations are checked, if an unpriveleged user can introduce an 
> > > etc.tar.bz2 file onto a drive that is checked before the real one, then 
> > > they can control the machine on the next reboot. We should check the 
> > > file for "root" ownership and that it is not writeable by anyone else 
> > > before loading it. Of course not being a bash master I'm not sure how to 
> > > write that...
> > >     
> > That won't work because a regular user could run "chmod 600 etc.tar.bz2"
> > and then a "chown root etc.tar.bz2" once they are done creating it. 
> > (unless we restrict execution of chown/chmod only to root)
> > 
> > You'll have to make sure a normal user doesn't have write access to the
> > root directory of any partition checked by linuxrc.  Unless you have
> > another idea .... ?
> 
> Not true, a non-priveleged user can't reassign ownership to another
> user... I ran a quick test and confirmed it on my box.

OK, that appears to be the case now.  I haven't tried that for a long
time on Linux.  BTW, I can still do it on HP-UX 11.0, just tried it.

That being the case, I'm still not sure it's worth checking in linuxrc.
Mainly because not all filesystems support the concept of "owner". 
Especially floppies & USB memory sticks which are formatted as FAT.

If you use LVM for your disk partitions (as specified in the DL docs),
then you won't have the problem because linuxrc doesn't check LVM
volumes.  If you use normal partitions, make sure that their root
directory is only root writable.  That with the fact that normal users
can't mount partitions should keep you safe.

 - BS

Re: [Devil-linux-develop] [PATCH] build/scripts/scripts/save-config - security hole?

[Tim <t....@co...>]

Heiko Zuerker wrote:

>>I came across what I  think is a small security hole. At least it
>>happens on my system, I think it is not unique. When the save-config
>>script makes the etc.tar.bz2 file, it leaves it world-readable (0644).
>>Any unpriveleged user who can mount the storage device can then copy the
>>file to their own directory or machine, and access the files that are
>>root-read-only, for example "shadow" and crack passwords etc at their
>>leisure.
>>
>>This patch chmods the etc.tar.bz2 file after successful creation to
>>0600. Also, I moved the "post-save-config" script check and call to
>>before the umount of the etc.tar.bz2 location, in the belief  that the
>>work of "post-save-config" script would be alot easier if it didn't have
>>to go and rediscover (possibly in error) where the file save-config just
>>wrote is stored... also, it shouldn't be run if the save failed I think.
>>
>>While I'm on the topic, I think another pontential hole is the linuxrc
>>script that discovers the etc.tar.bz2 file on boot... since multiple
>>locations are checked, if an unpriveleged user can introduce an
>>etc.tar.bz2 file onto a drive that is checked before the real one, then
>>they can control the machine on the next reboot. We should check the
>>file for "root" ownership and that it is not writeable by anyone else
>>before loading it. Of course not being a bash master I'm not sure how to
>>write that...
>>    
>>
>
>The only real secure way to prevent this is by using the gpg signing of
>the configuration.
>
>Currently only root is allowed to mount, but I found another hole in
>/etc/fstab, where a user is allowed to mount the floppy. I will turn this
>off imediately.
>  
>
I agree crypto gives the best security, but it is going to be complex, a 
management headache, and maybe more than most small installations need. 
The root only mount helps, but in some cases where the server has a hard 
drive used for stuff, it may already have a partion be mounted - say for 
tmp space. Now the user only needs to put the file there.

I can look into how to check for root ownership and make a patch...

Tim

Re: [Devil-linux-develop] [PATCH] build/scripts/scripts/save-config - security hole?

[Tim <t....@co...>]

Bruce Smith wrote:

>>While I'm on the topic, I think another pontential hole is the linuxrc 
>>script that discovers the etc.tar.bz2 file on boot... since multiple 
>>locations are checked, if an unpriveleged user can introduce an 
>>etc.tar.bz2 file onto a drive that is checked before the real one, then 
>>they can control the machine on the next reboot. We should check the 
>>file for "root" ownership and that it is not writeable by anyone else 
>>before loading it. Of course not being a bash master I'm not sure how to 
>>write that...
>>    
>>
>
>That won't work because a regular user could run "chmod 600 etc.tar.bz2"
>and then a "chown root etc.tar.bz2" once they are done creating it. 
>(unless we restrict execution of chown/chmod only to root)
>
>You'll have to make sure a normal user doesn't have write access to the
>root directory of any partition checked by linuxrc.  Unless you have
>another idea .... ?
>
> - BS
>
Not true, a non-priveleged user can't reassign ownership to another 
user... I ran a quick test and confirmed it on my box.

Tim

Re: [Devil-linux-develop] [PATCH] build/scripts/scripts/save-config - security hole?

[Heiko Z. <he...@zu...>]

>
> I came across what I  think is a small security hole. At least it
> happens on my system, I think it is not unique. When the save-config
> script makes the etc.tar.bz2 file, it leaves it world-readable (0644).
> Any unpriveleged user who can mount the storage device can then copy the
> file to their own directory or machine, and access the files that are
> root-read-only, for example "shadow" and crack passwords etc at their
> leisure.
>
> This patch chmods the etc.tar.bz2 file after successful creation to
> 0600. Also, I moved the "post-save-config" script check and call to
> before the umount of the etc.tar.bz2 location, in the belief  that the
> work of "post-save-config" script would be alot easier if it didn't have
> to go and rediscover (possibly in error) where the file save-config just
> wrote is stored... also, it shouldn't be run if the save failed I think.
>
> While I'm on the topic, I think another pontential hole is the linuxrc
> script that discovers the etc.tar.bz2 file on boot... since multiple
> locations are checked, if an unpriveleged user can introduce an
> etc.tar.bz2 file onto a drive that is checked before the real one, then
> they can control the machine on the next reboot. We should check the
> file for "root" ownership and that it is not writeable by anyone else
> before loading it. Of course not being a bash master I'm not sure how to
> write that...

I added the patch to 1.1.x and also updated 1.0.7.

-- 
Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-linux-develop] [PATCH] build/scripts/scripts/save-config - security hole?

[Heiko Z. <he...@zu...>]

>
> I came across what I  think is a small security hole. At least it
> happens on my system, I think it is not unique. When the save-config
> script makes the etc.tar.bz2 file, it leaves it world-readable (0644).
> Any unpriveleged user who can mount the storage device can then copy the
> file to their own directory or machine, and access the files that are
> root-read-only, for example "shadow" and crack passwords etc at their
> leisure.
>
> This patch chmods the etc.tar.bz2 file after successful creation to
> 0600. Also, I moved the "post-save-config" script check and call to
> before the umount of the etc.tar.bz2 location, in the belief  that the
> work of "post-save-config" script would be alot easier if it didn't have
> to go and rediscover (possibly in error) where the file save-config just
> wrote is stored... also, it shouldn't be run if the save failed I think.
>
> While I'm on the topic, I think another pontential hole is the linuxrc
> script that discovers the etc.tar.bz2 file on boot... since multiple
> locations are checked, if an unpriveleged user can introduce an
> etc.tar.bz2 file onto a drive that is checked before the real one, then
> they can control the machine on the next reboot. We should check the
> file for "root" ownership and that it is not writeable by anyone else
> before loading it. Of course not being a bash master I'm not sure how to
> write that...

The only real secure way to prevent this is by using the gpg signing of
the configuration.

Currently only root is allowed to mount, but I found another hole in
/etc/fstab, where a user is allowed to mount the floppy. I will turn this
off imediately.

-- 
Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-linux-develop] updateing documentation

[Bruce S. <bw...@ar...>]

> > an one more... what about 2.4.26? is it ready yet? :)
> 
> It's in CVS for a week... ;-)

And I'm running it on three different boxes since last week.  :-)

 - BS

Re: [Devil-linux-develop] [PATCH] build/scripts/scripts/save-config - security hole?

[Bruce S. <bw...@ar...>]

> I came across what I  think is a small security hole. At least it 
> happens on my system, I think it is not unique. When the save-config 
> script makes the etc.tar.bz2 file, it leaves it world-readable (0644). 
> Any unpriveleged user who can mount the storage device can then copy the 
> file to their own directory or machine, and access the files that are 
> root-read-only, for example "shadow" and crack passwords etc at their 
> leisure.
> 
> This patch chmods the etc.tar.bz2 file after successful creation to 
> 0600. Also, I moved the "post-save-config" script check and call to 
> before the umount of the etc.tar.bz2 location, in the belief  that the 
> work of "post-save-config" script would be alot easier if it didn't have 
> to go and rediscover (possibly in error) where the file save-config just 
> wrote is stored... also, it shouldn't be run if the save failed I think.

The chmod is a good idea.  Can't be too safe!  :-)

> While I'm on the topic, I think another pontential hole is the linuxrc 
> script that discovers the etc.tar.bz2 file on boot... since multiple 
> locations are checked, if an unpriveleged user can introduce an 
> etc.tar.bz2 file onto a drive that is checked before the real one, then 
> they can control the machine on the next reboot. We should check the 
> file for "root" ownership and that it is not writeable by anyone else 
> before loading it. Of course not being a bash master I'm not sure how to 
> write that...

That won't work because a regular user could run "chmod 600 etc.tar.bz2"
and then a "chown root etc.tar.bz2" once they are done creating it. 
(unless we restrict execution of chown/chmod only to root)

You'll have to make sure a normal user doesn't have write access to the
root directory of any partition checked by linuxrc.  Unless you have
another idea .... ?

 - BS

Re: [Devil-linux-develop] updateing documentation

[Heiko Z. <he...@zu...>]

> On Tue, Apr 27, 2004 at 03:11:34AM +0200, Diego Torres wrote:
>
> an one more... what about 2.4.26? is it ready yet? :)

It's in CVS for a week... ;-)

-- 
Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-linux-develop] updateing documentation

[Heiko Z. <he...@zu...>]

> On Mon, Apr 26, 2004 at 08:22:39PM -0400, Heiko Zuerker wrote:
>> >sorry, didn't know it...
>>
>> No problem.
>> You want to take over the docs? ;-)
>
> no time, but i could maintain that losetup part. you could also include
> may user of sourceforge, so it could be public :)
>
> but firstly, i hate you.. again!! :)
>
> look at scripts/util-linux or at
> http://cvs.sourceforge.net/viewcvs.py/devil-linux/build/scripts/util-linux?r1=1.20&r2=1.21
>
> maybe you wanted to write VERSION instead of VERSON, right?
>
>  if [ "$CONFIG_LINUX_VERSON" = "2.4" ];
>
> thats the reason why my losetup script wasn't working on the past few
> months... :!
>
> anyway, i'm going to fix it and test it right now :))

That byte must have gotten lost while I was checking in. It's a far way to
the SF CVS Server and there really can get something lost, just like
flying and your luggage doesn't arrive..... ;-)

-- 
Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-linux-develop] Feature Freeze DL 1.1.x -- Preparing for DL 1.2.0 release

[Zsiros Z. <zs...@ma...>]

2004-04-27, k keltez=E9ssel 13:26-kor Heiko Zuerker ezt =EDrta:
> Zsiros Zsolt wrote:
> > 2004-04-27, k keltez=E9ssel 01:18-kor Heiko Zuerker ezt =EDrta:
> >
> >>Hey Zsolt
> >
> >
> >>The lcd4linux.help and  lcd4linux.config are missing.
> >>Can you send them please ?
> >
> >
> > Hi!
> >
> > Of course. I attach it.
> >
> > Zsolt
>=20
> DONE
>=20
> It's all added.

Thank you :-)

Zsolt

Re: [Devil-linux-develop] [PATCH] IMQ complete patch (kernel + userspace)

[Heiko Z. <he...@zu...>]

Peter Frischknecht wrote:
> All the patches apply cleanly against a vanilla 2.4.26 kernel.
> 
> They have also been tested against the ALREADY patched 2.4.26 from
> DL...and they work.  HOWEVER, since the current version of DL ALREADY
> includes kernel pacthes for IMQ, the kernel specific patch is not needed
> (IMQ-kernel-2.4.diff).  The other patches must still be applied.
> Kernel Patches:
> IMQ-kernel-2.4.diff	   :basic IMQ device creation in the kernel
> IMQ-kernel-2.4.26-nat      :needed when IMQ/nat are used concurrently
> IMQ-kernel-netfilter-patch :iptables IMQ kernel module
> 
> Iptables patches:
> IMQ-iptables-1.2.9.diff    :iptables IMQ support
> 
> AFTER installing the patch, (patch p1 < filename.diff), there is an
> extra step needed.
> Under the src/iptables-1.2.9/extensions folder.  You have to:
> chmod +x .IMQ-test
> That is because the Makefile for iptables runs these patch tests for
> every kernel extension before building its own extensions. 
> 
> I have included the 2.6 patches as a novelty.  I have NOT used the 2.6
> kernel.  I have NOT tested the patches.
> I will soon try it...but for now...it is UNTESTED.
> 
> The 2.4 patches listed here are fully functional.  I have
> compiled/installed and ested them myself.  There should be no
> compilation errors.
> 

DONE

Heiko

Re: [Devil-linux-develop] Feature Freeze DL 1.1.x -- Preparing for DL 1.2.0 release

[Heiko Z. <he...@zu...>]

Zsiros Zsolt wrote:
> 2004-04-27, k keltezéssel 01:18-kor Heiko Zuerker ezt írta:
> 
>>Hey Zsolt
> 
> 
>>The lcd4linux.help and  lcd4linux.config are missing.
>>Can you send them please ?
> 
> 
> Hi!
> 
> Of course. I attach it.
> 
> Zsolt

DONE

It's all added.

Heiko

Re: [Devil-linux-develop] Feature Freeze DL 1.1.x -- Preparing for DL 1.2.0 release

[Zsiros Z. <zs...@ma...>]

2004-04-27, k keltez=E9ssel 01:18-kor Heiko Zuerker ezt =EDrta:
> Hey Zsolt

> The lcd4linux.help and  lcd4linux.config are missing.
> Can you send them please ?

Hi!

Of course. I attach it.

Zsolt

[Devil-linux-develop] [PATCH] build/scripts/scripts/save-config - security hole?

[Tim T. <t....@co...>]

I came across what I  think is a small security hole. At least it 
happens on my system, I think it is not unique. When the save-config 
script makes the etc.tar.bz2 file, it leaves it world-readable (0644). 
Any unpriveleged user who can mount the storage device can then copy the 
file to their own directory or machine, and access the files that are 
root-read-only, for example "shadow" and crack passwords etc at their 
leisure.

This patch chmods the etc.tar.bz2 file after successful creation to 
0600. Also, I moved the "post-save-config" script check and call to 
before the umount of the etc.tar.bz2 location, in the belief  that the 
work of "post-save-config" script would be alot easier if it didn't have 
to go and rediscover (possibly in error) where the file save-config just 
wrote is stored... also, it shouldn't be run if the save failed I think.

While I'm on the topic, I think another pontential hole is the linuxrc 
script that discovers the etc.tar.bz2 file on boot... since multiple 
locations are checked, if an unpriveleged user can introduce an 
etc.tar.bz2 file onto a drive that is checked before the real one, then 
they can control the machine on the next reboot. We should check the 
file for "root" ownership and that it is not writeable by anyone else 
before loading it. Of course not being a bash master I'm not sure how to 
write that...

Tim

Re: [Devil-linux-develop] Re: [Devil-linux-commit] build/config/etc/init.d network,1.31,1.32

[Bruce S. <bw...@ar...>]

> > > > I upgraded a firewall of mine and all the static route commands bombed.
> > > > After a little looking it appeared that the "if" statement below was
> > > > backwards, so I swapped the logic.  I didn't spend a lot of time looking
> > > > at the logic of the code, only the results of my routes (which now work)
> > > > I hope I didn't screw it up too bad, Friedrich!  :-)
> > > >       
> >   
> > > > > 				# add the route
> > > > > -				if [ -n "${netmask##*.*}" ]; then
> > > > > +				if [ -z "${netmask##*.*}" ]; then
> > > > > 					echo "   adding route to $CMD ${target}${netmask:+/$netmask}${gateway:+ via gateway $gateway} on $DEVICE"
> > > > > 					route add -$CMD ${target} ${netmask:+netmask $netmask} ${gateway:+gw $gateway} dev $DEVICE
> > > > > 				else
> > > > >         

Yeah, I committed the change last Friday.   I upgraded a couple servers
today to the latest, and it works for me now.

What revision number are you showing for the script?  Sometimes
sourceforge's anon CVS servers a little behind.  It should be 1.32.

Otherwise, it's a one character change you can do manually on line 266,
see above.

 - BS

Re: [Devil-linux-develop] Re: [Devil-linux-commit] build/config/etc/init.d network,1.31,1.32

[Tim T. <t....@co...>]

Bruce Smith wrote:

>>>I upgraded a firewall of mine and all the static route commands bombed.
>>>After a little looking it appeared that the "if" statement below was
>>>backwards, so I swapped the logic.  I didn't spend a lot of time looking
>>>at the logic of the code, only the results of my routes (which now work)
>>>I hope I didn't screw it up too bad, Friedrich!  :-)
>>>      
>>>
>>What does your routing entry look like? Would be good to know that as the 
>>code that you "fixed" looked ok to me - but I did not dig deeper into the 
>>matter.
>>    
>>
>
>ifcfg-eth0:
>ROUTE="$ROUTE 192.168.2.0/255.255.255.0:172.16.254.1"
>
>ifcfg-eth1:
>ROUTE="$ROUTE default/0.0.0.0:10.18.12.19"
>
>(some public IP's changed to protect the innocent :)
>
>  
>
>>>>				# add the route
>>>>-				if [ -n "${netmask##*.*}" ]; then
>>>>+				if [ -z "${netmask##*.*}" ]; then
>>>>					echo "   adding route to $CMD ${target}${netmask:+/$netmask}${gateway:+ via gateway $gateway} on $DEVICE"
>>>>					route add -$CMD ${target} ${netmask:+netmask $netmask} ${gateway:+gw $gateway} dev $DEVICE
>>>>				else
>>>>        
>>>>
>>This line was obviously from a patch from "Cameron Miller".
>>http://cvs.sourceforge.net/viewcvs.py/devil-linux/build/config/etc/init.d/network?r1=1.28&r2=1.29
>>and
>>http://cvs.sourceforge.net/viewcvs.py/devil-linux/build/config/etc/init.d/network
>>    
>>
>
>OK.  I just remembered you committing some changes recently.
>I didn't remember (or lookup) where they came from.
>
> - BS
>
This one got me too... has it been fixed yet? I don't see it when I do a 
cvs diff...

Tim

Re: [Devil-linux-develop] updateing documentation

[Diego T. <dt...@co...>]

On Tue, Apr 27, 2004 at 03:11:34AM +0200, Diego Torres wrote:

an one more... what about 2.4.26? is it ready yet? :)

-- 
-- gnupg keyfingerprint -- 48AF 5BF9 8F54 2966 64CC  2327 7CD0 DD91 B09D 5799
-- Use of a keyboard or mouse may be linked to serious injuries or disorders.
Diego Torres - dtorres at anthalia dot org - Madrid / España

Re: [Devil-linux-develop] updateing documentation

[Diego T. <dt...@co...>]

On Mon, Apr 26, 2004 at 08:22:39PM -0400, Heiko Zuerker wrote:
> >sorry, didn't know it...
> 
> No problem.
> You want to take over the docs? ;-)

no time, but i could maintain that losetup part. you could also include may user of sourceforge, so it could be public :)

but firstly, i hate you.. again!! :)

look at scripts/util-linux or at
http://cvs.sourceforge.net/viewcvs.py/devil-linux/build/scripts/util-linux?r1=1.20&r2=1.21

maybe you wanted to write VERSION instead of VERSON, right?

 if [ "$CONFIG_LINUX_VERSON" = "2.4" ]; 

thats the reason why my losetup script wasn't working on the past few months... :!

anyway, i'm going to fix it and test it right now :))


-- 
-- gnupg keyfingerprint -- 48AF 5BF9 8F54 2966 64CC  2327 7CD0 DD91 B09D 5799
-- Use of a keyboard or mouse may be linked to serious injuries or disorders.
Diego Torres - dtorres at anthalia dot org - Madrid / España

Re: [Devil-linux-develop] updateing documentation

[Heiko Z. <he...@zu...>]

Diego Torres wrote:
> On Mon, Apr 26, 2004 at 08:04:37PM -0400, Heiko Zuerker wrote:
> 
>>I'm personally not a friend of putting information like this in our 
>>docs, since somebody needs to keep them up-to-date. And as you all know 
>>that "somebody" currently doesn't exist which means I have to do it.....
> 
> 
> sorry, didn't know it...

No problem.
You want to take over the docs? ;-)

Heiko

Re: [Devil-linux-develop] updateing documentation

[Diego T. <dt...@co...>]

On Mon, Apr 26, 2004 at 08:04:37PM -0400, Heiko Zuerker wrote:
> 
> I'm personally not a friend of putting information like this in our 
> docs, since somebody needs to keep them up-to-date. And as you all know 
> that "somebody" currently doesn't exist which means I have to do it.....

sorry, didn't know it...
-- 
-- gnupg keyfingerprint -- 48AF 5BF9 8F54 2966 64CC  2327 7CD0 DD91 B09D 5799
-- Use of a keyboard or mouse may be linked to serious injuries or disorders.
Diego Torres - dtorres at anthalia dot org - Madrid / España

Re: [Devil-linux-develop] updateing documentation

[Heiko Z. <he...@zu...>]

Diego Torres wrote:
> here are some tips that could be copy & pasted from a linuxjournal
> article about losetup and aes encription to the dl documentation:
> 
> http://www.linuxjournal.com/article.php?sid=6481
> 
> (and the part about pam_mount is quite interesting for the sysadmins,
> its a pitty that we don't have pam on dl).
> 

I'm personally not a friend of putting information like this in our 
docs, since somebody needs to keep them up-to-date. And as you all know 
that "somebody" currently doesn't exist which means I have to do it.....

Heiko

[Devil-linux-develop] updateing documentation

[Diego T. <dt...@co...>]

here are some tips that could be copy & pasted from a linuxjournal
article about losetup and aes encription to the dl documentation:

http://www.linuxjournal.com/article.php?sid=6481

(and the part about pam_mount is quite interesting for the sysadmins,
its a pitty that we don't have pam on dl).

-- 
-- gnupg keyfingerprint -- 48AF 5BF9 8F54 2966 64CC  2327 7CD0 DD91 B09D 5799
-- Use of a keyboard or mouse may be linked to serious injuries or disorders.
Diego Torres - dtorres at anthalia dot org - Madrid / España

Re: [Devil-linux-develop] Feature Freeze DL 1.1.x -- Preparing for DL 1.2.0 release

[Heiko Z. <he...@zu...>]

Hey Zsolt

Zsiros Zsolt wrote:
>>I would like to add the lcd4linux package. I finished the tuning of
>>compilation script yesterday evening.
>>
>>The source is:
>>http://download.sourceforge.net/lcd4linux/lcd4linux-0.9.11.tar.gz
>>
>>The compilation script is attached.
>>
>>If I am really too late then it would be a first added feature id the
>>1.3.x tree.
> 
> 
> Heiko, Friedrich,
> 
> I didn't get neither accept nor reject about my "after last minute" new
> feature adding procedure ;-)
> So I attach a little patch for the kernel config. LCD4Linux needs PPDEV
> module to drive an LCD via paralel port.
> I attach also an init script for LCD4Linux.
> 
> Is there a general way to add a new package (what scripts/files need to
> be created and where, etc)?  I think about the file which adds the new
> package to the menuconfig.
> I found only some things in the manual but they fall short to create a
> working package.
> 
> 

The lcd4linux.help and  lcd4linux.config are missing.
Can you send them please ?

cu
   Heiko

Re: [Devil-linux-develop] crosscompiling

[Bruce S. <bw...@ar...>]

> You can not compile for an 686 on a 486, but you can compile for 486 on 
> a 686.

You cannot compile for a 486 on a 486, unless you have a couple years to
wait for it to complete!  ;-)

 - BS