Subject: Linux-Admin Digest #39
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Thu, 8 Sep 94 18:13:48 EDT

Linux-Admin Digest #39, Volume #2                 Thu, 8 Sep 94 18:13:48 EDT

Contents:
  Re: WARNING about shadow-mk package (Bauke Jan Douma)
  Re: UID 0 Passwd blues (David Kastrup)
  warm reboot w/ ethernet card troubles... (C.P.Townsend)
  Re: 2 ethernet cards? (Donald Becker)
  Re: Removing LILO ? How? (Marcus Barczak)
  Re: please help me with e2fsck!!!!!! ([email-masked])
  Re: HP Laserjet 4M Plus on Linux remote printer (Matthias M. Koehler)
  Re: virtual memory exhausted error (Rene COUGNENC)

----------------------------------------------------------------------------

From: [email-masked] (Bauke Jan Douma)
Subject: Re: WARNING about shadow-mk package
Date: 8 Sep 1994 12:35:44 GMT

In article <im14u2c.778823028@cegt201>,
Joe Zbiciak <[email-masked]> wrote:
>In <[email-masked]> [email-masked] (Bauke Jan Douma) writes:
>
>>In article <[email-masked]>, bjdouma <[email-masked]> wrote:
>
>>>Here's the snippet from the Makefile where login is installed:
>>>
>>>     install -m4755 login $(LOGINDIR)/_login
>>>     install -m4711 login.secure $(LOGINDIR)/login
>>>     
>>>So how secure can it be that there are no sources.
>>>Just asking.
>
>I apologize.  I am the author of the /bin/login replacement that is included
>in the shadow-mk package.  Mohan Kokal, the author of the shadow-mk package,
>is not to blame.  I had asked him not to distribute my (ugly) source.  :-)
>
>
>>Ok, I will now follow up on my earlier post about the shadow-mk
>>package.
>
>>I would advice anyone that has installed this package to remove it.
>
>This is not necessary.  The source for the binary in question will be
>posted later this evening.  I need to return to my linux box in order
>to upload it.  I do not have it readily available at the moment.
>
>>I have received an email from someone who also noticed the
>>installation of the login.secure binary, for which no source is
>>provided.
>
>I will post the source to the /bin/login replacement that I wrote, and trust
>on my own system.  I did not realize that the net would grow so suspicious.
>I should have known better.  :-)  After all, it could be snake oil, for
>all the net knows.  I realize now, especially after reading the files 
>focusing on security issues that were included with PGP, that it is *very*
>important to make the source available to public scrutiny.  Indeed, for
>similar reasons, I do not trust Clipper encryption (aside from the gov't
>back-door).

That was the reason for the suspicion, no sources, never referred to
in any README's, no explanation what it does.

>
>I will also post the version of GCC with which is was compiled, the version
>of libc with which it was compiled, and the compilation flags, so that
>each person make verify that it is indeed the source from which that 
>binary was created.  I will also have Mohan Kokal include the source in
>future versions of the shadow-mk package.
>
>In the meantime, I will detail how my patch works, and how it closes the
>now well known hole:
>
>My patch simply forces all argv[] elements beginning with a - to be no
>longer than 2 characters long, by writing a 0 into the third position
>after the dash.  Thus, if a user tries login -froot, the "r" in root
>would be overwritten, and the remainder, "oot", would be affectively
>truncated.
>
>Furthermore, my patch addresses another security issue, the misuse of
>the semi-documented -h switch, by disallowing anyone with a real uid greater
>than 100 from using it.
>
>Once all paramters have been patched, and the absence of -h is assured if
>UID>100, all parameters are passed to an unmodified /bin/_login.
>
>Again, as I said, the source will be posted later this evening, along with
>GCC version, libc version, optimization flags, and so on.
>
>>In his correspondence with the author of this package, that author,
>>in his helpfulness, asked for a temporary account on his machine, and
>>having been denied that, asked for the password file. The emailer
>>also told me he has observed the author of this package to be
>>bragging about violating computer security.
>
>
>To whom are you referring?  Mohan Kokal may have a number of accounts on
>various Linux boxes, for various reasons.  If you are referring to one
>of these accounts, please make known the people involved, as well as 
>circumstances in greater detail than you have.  This is an accusatory 
>statement based on heresay and circumstantial evidence. 
>
>Furthermore, "bragging about violating computer security" may be something
>as simple as "whoa... on an older Linux box, I noticed a hole in crontab
>that allowed such and such..."  or "yeah, I used rlogin to gain root--that
>old /bin/login was a joke."
>
>I, as well as some others, I am certain, would like to see a factual basis
>for this outright character assassination that you are making.  I have no
>reason to doubt that you may be able to support your statements.  However,
>I also have NO reason whatsoever to believe any of your closing statements.

I can support these statements; in trying to avoid just that, a
"character assassination" on hearsay, I specifically did not mention
a name, but asked the emailer of these statements to follow up on my
posting as soon as possible and to elaborate his first hand
experiences, to which he agreed.  He emailed me back that he had in
fact posted that followup, but I have not seen it in any of the
threads, including this one.

Btw, stating someone asked for an account, for the password file, or
is bragging about violating computer security can hardly be called an
attempt at character assassination - as you appear to admit yourself;
they may be, however, relevant facts to the issue. I had no reason to
doubt that what the emailer said had in fact happened to him.

I'm not sure now if I should reveal the emailer's name.  I hope he
would speak up. I will not disclose his email to me here in public,
but will send it to Mohan Kokal.
Anyway, given these statements, I felt it warranted a warning about
the shadow-mk package; I was not alone in this.

If, in fact, my remarks are interpreted by you and others to be an
unfounded "character assassination", I apologize to Mohan Kokal.

>
>--Joseph R. M. Zbiciak
>  Systems Administrator & Programmer
>  Texas Networking Systems, Inc.
>
>
>                                                := Joe Zbiciak == im14u2c@ =:
>                                                :- - cegt201.bradley.edu - -:
>                                                : -  camelot.bradley.edu  - :
>           If it works, Don't fix it.           :-Finger for PGP Public Key-:
>                                                :======= DISCLAIMER: =======:
>                                                :    He flamed me first!    :
>                                                +---------------------------+
>

[email-masked]

------------------------------

From: [email-masked] (David Kastrup)
Subject: Re: UID 0 Passwd blues
Date: 7 Sep 1994 20:33:10 GMT

[email-masked] (Andrew R. Tefft) writes:

>In article [email-masked], [email-masked] (Kevin Lentin) writes:
>>Anton de Wet ([email-masked]) wrote:
>>> I ran accross an inconvenient ``feature'' of the passwd program yesterday.
>>> On one of our Linux boxes we have 3 UID 0 users --- root and two others. 
>>> Since initial setup a week ago, everything was working fine, but suddenly
>>> the root password was invalid :-( After some investigation and experimenting
>>> we found that one of the users had changed his password and that this changes
>>> all the  UID 0 passwords to the same thing.
>>
>>Having multiple accounts with the same uid and different names are bound to
>>cause trouble. Some programs may use other methods besides getuid() to
>>figure out who you are. $LOGNAME. getlogin(), who knows what they might
>>return.
Bull. This is quite common for "fake" users, who have a a program installed
as a shell which is not so very shell-like.

Examples: uucp (sometimes), halt, sync ...
Very common: to halt the system from the login prompt, you just log in as
halt.
-- 
 David Kastrup        [email-masked]          
 Tel: +49-241-72419 Fax: +49-241-79502
 Goethestr. 20, D-52064 Aachen

------------------------------

From: [email-masked] (C.P.Townsend)
Subject: warm reboot w/ ethernet card troubles...
Date: 8 Sep 1994 14:21:23 -0400

I recently installed a d-link D200 ethernet card (an NE*000 clone)
in my box and I've been having troubles with warm boots ever since.  
If I reboot using shutdown -r it hangs right after configuring plip 
(i.e. at the probe for ethernet cards), same if I use the reset 
button from any of the 'safe' places.  I do not have any problem 
with cold boots.
Does anybody know of any way to fix this *without* recompiling the
kernel?  The card is at 0x300, irq 11.  I'm not real happy about leaving
my box in state where it can't bring itself up after a reboot...

Thanks,

townsend

-- 
Johnny Appleseed wore a coffee sack

------------------------------

From: [email-masked] (Donald Becker)
Subject: Re: 2 ethernet cards?
Date: 7 Sep 1994 16:52:05 -0400

In article <[email-masked]>,
Anto Daryanto <[email-masked]> wrote:
>Hi,
>in our departement we need a router. I know that someone has already post 
>it, but I missed it somehow. Is it possible to have a linux box that uses 
>2 ethernet cards? What kind of configurations do you have to change in 
>the kernel?

Read

http://cesdis.gsfc.nasa.gov/linux/misc/multicard.html

I've included it here:

<html>
<title>Multiple Linux ethercard HowTo</title>
<h1><a name="top">Mini-HowTo on using multiple ethercards with Linux</h1>
<body>

<P>This is an short note on configuring  Linux to recognize multiple ethernet
adapters. 

<P>For most people running a standard Linux distribution, just add this
line to the top of your <i>/etc/lilo.conf</i> file and re-run `lilo': 

<listing>
append = "ether=0,0,eth1"
</listing>

<P>That's all there is to it.  The next time you boot Linux should
recognize your second ethercard.

<h2>What you did, and how you did it.</h2>

<P>By default a stock Linux kernel probes for a single ethercard, and once
one is found the probe ceases.  There are three defined ways to cause the
kernel to probe for additional cards.  In increasing order of difficulty and
permanence they are:

<ul>
<li>Passing parameters to your kernel at boot time.
<li>Configuring your boot loader to always pass those parameters.
<li>Modifying the kernel netcard probe tables in <b>drivers/net/Space.c</b>.
</ul>

<P>For most people the second method is most appropriate, and it's the
one that was described above.

<h2>Passing parameters using your boot loader</h2>

<P>In the following instructions it's assumed that you are using the standard
Linux boot loader, `<i>LILO</i>'.

<P>The Linux kernel recognizes certain parameters passed at boot-time.  Most
often these parameters specify aspects of the configuration that cannot be
determined at boot-time.  For network adaptors the following parameter is
recognized: 
<listing>
ether=<IRQ>,<IO-ADDR>,<PARAM1>,<PARAM2>,<NAME>
</listing>

Valid numeric arguments may be in decimal, octal (with a leading '0')
or hexadecimal (preceded by a '0x').  The first non-numeric argument
is taken to be the <i>NAME</i> of the device.  Empty arguments are
taken to be zero, and any omitted arguments before the name are left
unchanged.
<dl>
<dt>IRQ
<dd>This entry specifies the IRQ value to be set (on boards with
software-settable IRQs) or used (on boards with jumpered IRQs).  A
value of '0' means to read the IRQ line from the board (if possible)
or use autoIRQ if the board doesn't provide a way to read the IRQ.
<dt>IO-ADDR
<dd>This entry specifies a single base I/O address to probe.
A value of zero specifies that all reasonable I/O address are to be probed.

<P>Normally an I/O region reservation map is used to decide if a
location can be probed.  This map is ignored if an I/O address is specified.
This allows the "reserve=<IO-ADDR>,<EXTENT>" parameter to exclude
other device probes from an IO region. 

<dt>PARAM1,PARAM2
<dd>Originally these entries were for specifying the memory address of
adaptors that use shared memory, like the WD8013.  Over time they have
been extended to provide other driver-specific information.

<dt>NAME
<dd>The name of a predefined device.  The stock kernel defines at
least "eth0", "eth1", "eth2", and "eth3".  Other devices names (e.g.
for PPP, SLIP, or a pocket ethernet device) may exist but will have
different semantics.

</dl>

<P>LILO provides two ways to pass these boot-time parameters to the kernel.
The most common way to do this is to type them immediately after specifying
the name of the boot image.  The following example enables all four of the
available probe slots.
<listing>
linux ether=0,0,eth1 ether=0,0,eth2 ether=0,0,eth3
</listing>

<P>Of course this is pretty complicated to type in at each boot, and
would preclude unattended reboots.  You can make the kernel parameters
permanent by adding an "append" line to your LILO configuration file,
<i>/etc/lilo.conf</i>, and running LILO to install your updated configuration.
<listing>
append = "ether=0,0,eth1 ether=0,0,eth2 ether=0,0,eth3"
</listing>

<h2>Modifying your kernel</h2>

<P>If it's possible for you to configure your system without modifying
the kernel source, I recommend that you do so.  Modifying the source
code isn't self-documenting and results in extra complications at
upgrade time.  Still there are a few instances where it is
appropriate:

<ul>
<li>When you need to enable more than four devices.  (The
drivers/net/Space.c only has entries for eth0...eth3.)
<li>When you must limit the probe types to a subset of possible card types
e.g. when a probe confuses a different type of device.
<li>When you want a device name other than eth<i>N</i>.
</ul>

If you've decided to go this route, edit the device list in
drivers/net/Space.c to insert your desired values.  If you need to add
a new device take care that you preserve the chaining: use the
existing list entries as a guide.

<h2><a name="cardnotes">Special notes on the specific device probes</h2>

<h3>The 3c509 in ISA mode</h3>

<P>The 3c509 has a unique feature that allows truly safe probing on the
ISA bus.  This is great, but unfortunately for us this method doesn't
mix well with the rest of the probes.

<P>The most noticeable aspect is that it's difficult to predict
<i>a priori</i> which card will be accepted "first" -- the order is based
on the hardware ethernet address.  That means that the ethercard with the
lowest ethernet address will be assigned to "eth0", and the next to "eth1",
etc.  If the "eth0" ethercard is removed, they all shift down one number.

<P>A related aspect is that it's not possible to leave an "earlier"
card disabled, enable a card at an address or IRQ different than the
EEPROM setting, or enable a card at a specific address. 

<h3>The EISA 3c579 and the 3c509 in EISA mode</h3>

Kernels before 1.1.25 will not correctly probe for multiple EISA-mode cards.
If multiple "ethN" entries are specified the *same* 3c5*9 card will be
found multiple times.
The work-around is to specify the slot-based I/O address explicitly.

Kernels after 1.1.25 will correctly find multiple EISA-mode cards, and
will continue to find additional ISA-mode adaptors after all of the
potential EISA-mode addresses are checked. 
</body>
<hr>
<a href=#top>Top</a><br>
<a href="http://cesdis.gsfc.nasa.gov/linux/linux.html">Linux at CESDIS</a><br>
<address><i>Author: </i><a href="http://cesdis.gsfc.nasa.gov/pub/people/becker/whoiam.html">Donald
Becker</a>, [email-masked]</address>
The HowTo right-to-copy is given in
<a href="http://sunsite.unc.edu/mdw/HOWTO/HOWTO-INDEX-6.html">
http://sunsite.unc.edu/mdw/HOWTO/HOWTO-INDEX-6.html</a>
</html>
-- 
Donald Becker                                     [email-masked]
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center,  Greenbelt, MD.  20771
301-286-0882         http://cesdis.gsfc.nasa.gov/pub/people/becker/whoiam.html

------------------------------

From: [email-masked] (Marcus Barczak)
Subject: Re: Removing LILO ? How?
Date: 8 Sep 1994 22:45:32 +1000

In <laud.779002298@marsh> [email-masked] (Daniel Lau) writes:

>Can someone direct me in nicely removing LILO so that either my MS-DOS
>partition will boot up, or my new OS will boot up?

If you have LILO on the Master Boot Record of your first hard drive
/dev/hda you can remove it by booting DOS and running "fdisk /mbr".
This restores the MBR on the drive, but this may be a DOS 6.0 specific
option, I can't quite remember.  You may want to check it out before
going in boots n' all.

However make sure you have both a bootable DOS floppy and a bootable
Linux floppy handy, in particular the Linux floppy as you will have no
way of booting your linux partition.

Cheers,
Mull
-- 
Marcus Barczak ->*<- [email-masked]

------------------------------

From: [email-masked]
Crossposted-To: comp.os.linux.help
Subject: Re: please help me with e2fsck!!!!!!
Date: 8 Sep 1994 14:42:22 GMT

Thank you all very much for your help in fixing this e2fsck problem!
The problem was really that I used it on a mounted filesystem.

And please excuse my hard words about Linux in my first post, but
I was too angry this morning. I was at the same stage as 3 month ago!
Your help was really great and I withdraw everything I said about Linux 
at this post.

But there is still a advantage of it: The feedback was much better 
as on my question I posted half a year ago.

So let's thank you again 
                            bye
                                    Ludwig

------------------------------

From: [email-masked] (Matthias M. Koehler)
Subject: Re: HP Laserjet 4M Plus on Linux remote printer
Date: 8 Sep 1994 09:02:53 GMT

Hendrik Klompmaker ([email-masked]) wrote:
: Can anybody help me on this one. I have a Laserjet 4M Plus on ethernet (mio) 
: that bootp's from my linux box. ...
: Postscript files are fine with the entry I made in the printcap file but 
: ASCII files won't print. ...

Do you get the 'staircase'-effect, where following line starts right below
the end of the previous line?  No need to fiddle with tftp and so on!

Simply make a second entry in your printcap with a different
printername and the line :rp=text: instead of :rp=raw:. I use another
queue-directory as well, but don't think that this is mandatory.
Your JetDirect manual should have a chapter "configuring for lpd",
where you will find more details.

: Thanks in advance.

Hope it helps,
Matthias
--
Ingenieurbuero Matthias M. Koehler         [email-masked]
Konrad-Adenauer-Str. 7            Tel. +49-6106-638222
D-63110 Rodgau                    Fax  +49-6106-638223
***** Internet im Sueden und im Osten Frankfurts *****

------------------------------

From: [email-masked] (Rene COUGNENC)
Subject: Re: virtual memory exhausted error
Date: 6 Sep 1994 20:25:10 GMT
Reply-To: [email-masked] (Rene COUGNENC)

Ce brave Paul Julie ecrit:

> During compiling of X windows programmes:
> I get this "virtual memory exhausted error"
> from the system after using the gnu compiler.  
>
> I have 8 Meg of RAM and a 12 MB swap space. That should be 
> suffice to run at least 5-6 xterms.

I have 8Mb RAM, 8Mb Swap, and actually 9 Xterm's on the screen.
(well, not really xterm, rxvt to be honest).

Verify that your swap is used; you must have somewhere in an "rc"
file something like "swapon /dev/swap-partition", or "swapon -a",
in this case  the partition must be declared in /etc/fstab, for
exemple:
 
# device        directory       type    options        
/dev/hda2       none            swap    swap      

> Now I know that if I installed SCO ODT 2.0 on my machine
> at home I would be able to bring up 1-2 xterms and that
> would be the max.  
                                :-))
--
 linux linux linux linux -[ [email-masked] ]- linux linux linux 

------------------------------

** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [email-masked]

You can send mail to the entire list (and comp.os.linux.admin) via:

    Internet: [email-masked]

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Admin Digest
******************************