Subject: Linux-Development Digest #130
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Tue, 6 Sep 94 14:13:09 EDT

Linux-Development Digest #130, Volume #2          Tue, 6 Sep 94 14:13:09 EDT

Contents:
  Re: Alpha Linux (Anton Ertl)
  Re: IDE Performance enhancement (Mark Lord)
  Re: hdparm.c and/or new fast-IDE won't work now! (Mark Lord)
  Re: BUG/MISFEATURE: umsdos File system (Jacques Gelinas)
  clnttcp_create: RPC: Program not registered (Mark Fernyhough)
  Re: Linux console to SCO comp. prob (Stephen Harris)
  Re: Kernel change summary 1.1.45 -> 1.1.46 (Brad Midgley)
  Re: clnttcp_create: RPC: Program not registered (Mitchum DSouza)
  help SCSI aha1542 broken since 1.1.36 now in 1.1.49 (BARRY TITMARSH)
  Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library) (Robert Sanders)
  Re: IDE Hard Drives w/ over 1024 cylinders (Patrick J. LoPresti)
  Novell routing between IPX/TCPIP? (Bob Kaehms)
  Re: IDE Performance enhancement (Davor Jadrijevic)
  Re: Alpha Linux (Peter Holzer)
  Re: Linux - my first impressions (Joern Rennecke)
  Re: Alpha Linux (Albert D. Cahalan)
  Americans vs. Europeans (was Re: Unicode...) (Richard L. Goerwitz)
  Re: Kernel change summary 1.1.45 -> 1.1.46 (John McClary Prevost)

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

From: [email-masked] (Anton Ertl)
Subject: Re: Alpha Linux
Date: 6 Sep 1994 14:21:25 GMT

In article <[email-masked]>, [email-masked] (Douglas Ambrisko) writes:
|> The biggest task with the
|> Alpha is making everything 64 bit clean and this will apply to the EISA
|> drivers.

Only if Linux on the Alpha will be a 64-bit-OS. If it will be, I hope
that they do not repeat the OSF/1 idiocy of having only 32-bit ints.

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
[email-masked] Most things have to be believed to be seen

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

From: [email-masked] (Mark Lord)
Subject: Re: IDE Performance enhancement
Date: 6 Sep 1994 14:23:38 GMT

In article <[email-masked]> [email-masked] writes:
>
>iozone, while not useful for anthing else, would be perfect for this kind
>of empirical testing, rather than kernel compilation.

IOZONE is very sensitive to the fragmentation of the filesystem on which
it is used.  

To get meaningful results, run it on a newly created empty filesystem.

On my system, multiple-sector-mode increases IO throughput by about 10%
with 1.1.49.
-- 
[email-masked]    Mark Lord       BNR Ottawa,Canada       613-763-7482

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

From: [email-masked] (Mark Lord)
Subject: Re: hdparm.c and/or new fast-IDE won't work now!
Date: 6 Sep 1994 14:29:36 GMT

In article <[email-masked]> [email-masked] writes:
>
>I'm having a problem with hdparm as well. I invoke hdparm -m16 /dev/hda,
>and I get this message:
>/dev/hda:
> setting mult-count to 16
> multcount = 16
>
>But when I read /var/adm/messages, I came across this:
>
>Sep  6 06:53:05 reynolds kernel:   hda: enabled 16-sector multiple mode
>Sep  6 06:53:05 reynolds kernel: hda: multwrite_intr: status = 0xd0
>Sep  6 06:53:05 reynolds last message repeated 7 times
>Sep  6 06:53:05 reynolds kernel: hda: reset multiple mode to 0
>
>I quite sure that my system can do 16-sector multiple mode, because I've had
>great success with similar shareware programs for Messy-DOS. The hard drive
>subsystem is a Conner CP3044 IDE drive, hooked up to a generic 16 bit
>Super I/O card. Any suggestions would be appreciated. (-:

As noted in the documentation, some CONNER drives have problems.

Try it with a smaller setting, such as:  hdparm -m8 /dev/hda
Also, try with irq-unmasking off (default:  hdparm -u0 -m8 /dev/hda

-- 
[email-masked]    Mark Lord       BNR Ottawa,Canada       613-763-7482

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

From: [email-masked] (Jacques Gelinas)
Subject: Re: BUG/MISFEATURE: umsdos File system
Date: Tue, 6 Sep 94 13:39:30 GMT

[email-masked] (Andrew Davison) writes:

>Don't know whether anyone else has picked this one up...

>The umsdos file system uses a file --linux.--- to store the non-fat file
>information in. This file is invisible to the user, but apparently not to
>the file system. If you try to remove a directory on a umsdos partition it
>balks because the directory is not empty (---linux.--- does not match the * 
>wildcard).

This case is managed properly. When a rmdir is done, the directory
is probe for emptyness and --linux-.--- is properly checked for. There are
different things that may cause this.

1-A file was added with DOS and the directory was not "umssync'ed".
  This means that umsdos is not aware of the added file and. Apply
  umssync as root and you will see those "hidden" file appear.

2-One weakness of umsdos is the way it manage hard links. The following
  script will always fail (rmdir ...).

  mkdir /tmp/a
  mkdir /tmp/b
  echo hello >/tmp/a/file
  ln /tmp/a/file /tmp/b/file
  rm /tmp/a/file
  rmdir /tmp/a

  Even if /tmp/a is logically empty, a hidden file is still there. Umsdos
  implement hard links as "symlinks" to a hidden file in the original
  directory where the first link was created. The solution to this will
  be to move all hardlinks's hidden file to a special directory /.links.
  This is causing another problem with opened file so it is not done
  now.

-- 

========================================================
Jacques Gelinas ([email-masked])
Maintainer of US4BINR [email-masked]

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

From: [email-masked] (Mark Fernyhough)
Subject: clnttcp_create: RPC: Program not registered
Reply-To: [email-masked]
Date: Tue, 6 Sep 1994 14:58:19 GMT

After installing libc-4.6.7 i started getting a few problems. First one
was that the location of utmp changed which was ok to fix, but the second
was the message:-

clnttcp_create: RPC: Program not registered

This occured when logging in:-

 Password: 
 Last login: Mon Sep  5 17:06:29 on tty1
 clnttcp_create: RPC: Program not registered  <-------------
 Linux 1.1.49. (Posix).
 You have mail.

and also when when untarring a file:

 pc64:~/net> tar xvzf net-tools-1.1.46.tar.gz
 COPYING
 Configure.sh
 Install.sh
 Makefile
 README
 README.hostname
 arp
 clnttcp_create: RPC: Program not registered  <-------------
 arp.c

Does anyone now how to fix this? Do i have to recompile binaries or do i have
to redo the /etc/rpc file with a new entry..........?

Thanks in advance.

Mark Fernyhough

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

From: [email-masked] (Stephen Harris)
Subject: Re: Linux console to SCO comp. prob
Date: Tue, 6 Sep 1994 12:57:07 GMT

Keith Smith ([email-masked]) wrote:
: Oh vomit.  The Fkey sequences under linux really suck.  They would be
: GREAT if they followed a contiguous pattern, but they don't do that.  I
: don't care what DEC did.  A suggestion would be something like:

If you don't like them, then build your own keymap file and termcap entry.

The point is that programs can't make assumptions about keyboard maps.
That was the reason for termcap and terminfo in the first place!

: 'Splain where F22 is on a VT100 will ya?

And explain where it is on a PC keyboard?  I'm damn sure there isn't any
key above F12 on my keyboard.

: The WY-50 uses a CTRL-A leadin with characters from the ASCII chart
: starting with '@' == 1 and work their way up the ASCII chart IN ORDER,
: following the character with a CR.

Isn't this the same keyboard where LEFT-ARROW produces the same code as
BACKSPACE?  And where DOWN-ARROW produces a ^M

*Not* my favourite keyboard!  IMPOSSIBLE to tell whether the backspace or
left arrow was pressed.  And they sure are used for different purposes!
(stty erase '^H' anyone?)

: I have _NEVER_ seen a consistant DEC VT Function key keymap, but you can

Strange.  VT220, VT320, VT420, Wyse85, Wyse99GT, MS-Kermit all produce the
same keycodes for F5->F20  (using Shift on MS-Kermit to get F11-F20).
Err, also Liberty and Altos5.

: So if you wanna emulate the "Most common" sequences you'd best pick the
: Wyse keyboard sequences.

Still disagree.  The most common terminal emulation that I have seen is that of
a DEC VT.  But this is besides the whole point of the argument.

1) Linux keyboard is reprogrammable
2) Software with keyboard sequence limits is severly broken.
-- 

rgds
Stephen

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

From: [email-masked] (Brad Midgley)
Subject: Re: Kernel change summary 1.1.45 -> 1.1.46
Date: 6 Sep 1994 14:18:10 GMT

In article <[email-masked]>,
John McClary Prevost <[email-masked]> wrote:

[multi-user mode changing of append-only/imutable bits]

>Hmm.  Doesn't this decrease the usefulness of the append-only and
>immutable bits?  As I understood it, the rational for adding these
>attributes was to make it harder for would-be system crackers to do
>serious damage or remove traces of their work.  (i.e., they break in,
>hack root, try to remove entries from /var/adm/syslog, and discover
>that they have to be in single user mode to do anything except append
>to it.)

For this purpose, the raw device must also be immutable.  But what
about mknod?  How would mknod know which created-devices should be
immutable?  a root break-in could do anything he wanted to the file
system with access a writable raw device (albeit difficult).

Disallowing mknod exept in single-user mode would be overkill.

Brad
-- 

Brad

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

From: [email-masked] (Mitchum DSouza)
Subject: Re: clnttcp_create: RPC: Program not registered
Date: 6 Sep 1994 15:18:25 GMT

In article <[email-masked]>, [email-masked] (Mark
Fernyhough) writes:
|> After installing libc-4.6.7 i started getting a few problems. First one
|> was that the location of utmp changed which was ok to fix, but the second
|> was the message:-
|> 
|> clnttcp_create: RPC: Program not registered
|> 
|> This occured when logging in:-
|> 
|>  Password: 
|>  Last login: Mon Sep  5 17:06:29 on tty1
|>  clnttcp_create: RPC: Program not registered  <-------------
|>  Linux 1.1.49. (Posix).
|>  You have mail.
|> 
|> and also when when untarring a file:
|> 
|>  pc64:~/net> tar xvzf net-tools-1.1.46.tar.gz
|>  COPYING
|>  Configure.sh
|>  Install.sh
|>  Makefile
|>  README
|>  README.hostname
|>  arp
|>  clnttcp_create: RPC: Program not registered  <-------------
|>  arp.c
|> 
|> Does anyone now how to fix this? Do i have to recompile binaries or do i
|> have
|> to redo the /etc/rpc file with a new entry..........?

Hmmm very interesting...

First before people start asking, libc-4.6.7 is not for public use yet, so
expect problem (perhaps) like these.

What rpc services do you use ?? NIS/YP, NYS, NFS, AMD ? Have you changed
anything recently ??

One of the major changes is that the res* and inet* stuff from bsd4.4/bind493b9
have been integrated with our libc.

Mitch

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

Date: Tue, 6 Sep 1994 13:12:08 EST
From: BARRY TITMARSH <[email-masked]>
Crossposted-To: comp.os.linux.help
Subject: help SCSI aha1542 broken since 1.1.36 now in 1.1.49

So please. Who is working on scsi aha1542B/C code now..
I have a broken aha1542 since 1.1.36 and still no fix.
please mail me if you have info on who is the current maintainer of
scsi for aha1542
thnaks.
see my other postings about scsi bug in 1.1.37--->>--1.1.49
thnaks.

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

From: [email-masked] (Robert Sanders)
Subject: Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library)
Date: 06 Sep 1994 15:20:13 GMT

On 6 Sep 1994 00:09:34 -0400, [email-masked] (David Barr) said:

> Huh?  A cache is only good for speed-up purposes.  A cache does you no
> good if you have two incompatible libraries around of the same name
> that you need simultaneous access to.  (Oh, like say X11R5 libX11.so and
> X11R6 libX11.so)  In fact a cache needlessly randomizes and obscures
> the process.  Having compile-time library paths (and filenames) is in
> no way "binary bloat".

But now you're missing the point; Linux shared libraries have the
concept of major revisions for incompatible changes.  You wouldn't
havbe two libX11.so files lying around.  You'd have libX11.so.3 (a
symlink to libX11.so.3.1.0 or something) and libX11.so.4 (a symlink to
libX11.so.4.something).  ldconfig sets up the symlinks, of course.
X11R6 binaries would load libX11.so.4 and X11R5 binaries would load
libX11.so.3.

For example:

$ ldd /usr/bin/X11/xv
        libX11.so.3 (DLL Jump 3.1) => /usr/X386/lib/libX11.so.3.1.0
        libgr.so.1 (DLL Jump 1.3) => /usr/lib/libgr.so.1.3
        libm.so.4 (DLL Jump 4.5pl21) => /lib/libm.so.4.5.26
        libc.so.4 (DLL Jump 4.5pl21) => /lib/libc.so.4.5.26

The filename on the left is the compile-time library name (note the
trailing major revision number), the parenthesized expression is the
major&minor revision it was compiled against, and the filename on the
right is the library it currently resolves to.

I'm not saying storing library paths in the executable isn't useful,
but it seems to me that explicit versioning like Linux does is
flexible and powerful for any non-synthetic situations.  I don't have
any trouble keeping two (or more) incompatible libwhatever.so
libraries around.  In fact, I can keep them in the same place.

  -- Robert

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

From: [email-masked] (Patrick J. LoPresti)
Subject: Re: IDE Hard Drives w/ over 1024 cylinders
Date: 06 Sep 1994 15:22:29 GMT

>>>>> Daniel Quinlan <[email-masked]> writes:

 > Ack!  This isn't needed any more.  Linux kernel versions after
 > 1.1.40 (or thereabouts) support EIDE drives directly.

1.1.37, I believe.

 > Yggdrasil's Fall revision includes that support.

Cool.  At this point, though, I think it is the only distribution
which does.  Until more do, it is probably worth mentioning the hack,
but with a disclaimer that it is unnecessary if you use a current
kernel.

- Pat

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

From: [email-masked] (Bob Kaehms)
Subject: Novell routing between IPX/TCPIP?
Date: 6 Sep 1994 15:33:06 GMT

(the way tin's acting, I may have asked this a while back, but since
I didn't hear any replies....)

Does anyone have any ideas on how I could turn Linux into a router for
both TCPIP and IPX?  what would it take to get IPX routing available on
Linux? Buy-in from Novell?  Anyone familar enough with IPX to know whether
or not this is doable without Novell?

Thanks for any pointers...

-bob kaehms

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

From: [email-masked] (Davor Jadrijevic)
Subject: Re: IDE Performance enhancement
Date: 6 Sep 1994 15:32:42 GMT

Patrick Doyle ([email-masked]) wrote:
: They are included in later revision kernels (I'm not too sure when
: they first appeared).  They have to be specifically enabled, however,
: using the "hdparm" program.

Yes, I did hdparm on 1.1.49 (and the same (de)performance was observed
from the times around 1.0.x kernels). I test it by cat bigfile > /dev/null
and ls -lR > /dev/null, to produce lots of disk activity (more than 8MB RAM
can take). When it comes into stationary stage, I timed cat+ls performance 
and saw -5% on Conner 240M with mmode 16. mkfs speed isn't important to me.

d.
--
<[email-masked]>, <[email-masked]>
================ Davor Jadrijevic ====================

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

From: [email-masked] (Peter Holzer)
Subject: Re: Alpha Linux
Date: 6 Sep 1994 15:40:03 GMT

[email-masked] (Anton Ertl) writes:

>In article <[email-masked]>, [email-masked] (Douglas Ambrisko) writes:
>|> The biggest task with the
>|> Alpha is making everything 64 bit clean and this will apply to the EISA
>|> drivers.

>Only if Linux on the Alpha will be a 64-bit-OS. 

I sure hope it will be. Who wants a 32 bit OS on an Alpha?

>If it will be, I hope
>that they do not repeat the OSF/1 idiocy of having only 32-bit ints.

Then you have to drop either the 16 bit or the 32 bit int type. Both
options may make some people unhappy. The 32 bit int is a reasonable
compromise. It also breaks all those programs which assume that a
pointer and an int are just the same thing, which is a good thing IMHO.

        hp
-- 
   _  | [email-masked] | Peter Holzer | TU Vienna | CS/Real-Time Systems
|_|_) |------------------------------------------------------------------------
| |   | It's not what we don't know that gets us into trouble, it's
__/   | what we know that ain't so. -- Will Rogers

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

From: [email-masked] (Joern Rennecke)
Subject: Re: Linux - my first impressions
Date: 6 Sep 1994 17:26:24 GMT

[email-masked] (Kees J. Bot) writes:

>[email-masked] (Rob Janssen) writes:
>>
>>In <[email-masked]> [email-masked] (Kees J. Bot) writes:
>>
>>>[email-masked] (Rob Janssen) writes:
>>
>>>>In <[email-masked]> [email-masked] (Kees J. Bot) writes:
...
>>>>>The LILO method is rather crude.
>>
>>>>I don't think so...
>>
>>>>- LILO does not require the boot image to be on contiguous sectors
>>
>>>No requirement of any other loader I know.
>>
>>Have a look at SYS V systems...  They use a separate filesystem for
>>the bootimages where files always use contiguous blocks.

>Brrr.  I'd rather not look.  I'd rather critize smaller issues of decent
>operating systems.

>>>>- LILO can boot many different kernels and also other operating systems
>>
>>>Many different kernels *if* all of them have been mapped.  They must be
>>>carefully mapped whenever a new kernel is installed.  That's what I mean
>>>with crude.
>>
>>No, this is done only once when configuring LILO.  From then on, all
>>kernels will be mapped simply by running the installer.

>Precisely, they must be carefully mapped by running the installer each
>time a new kernel is made.  (I never supposed one needed to reconfigure
>the whole lot over and over.)

...
>>>>I think it is a good program, and running its installer after building
>>>>the kernel is not a problem at all.  It is even done in the same
>>>>"make zlilo" command.
>>
>>>Inflexible.
>>>I like to hack code on one system, copy the resulting kernel image to
>>>another system with a simple 'rcp' command, and test the new kernel on
>>>this other system.  Both systems are running Minix-386vm, with a
>>>bootstrap system written by myself that understands Minix filesystems.
>>
>>That will really shine on an ext2 partition!

>Minix-386vm doesn't have ext2.  If so then the boot program would be
>extended to support it.  It is not that much work to just be able to
>read a file system.

I'm still happily using the xiafs filesystem because it has proven to
be more robust. Scrapping all my files for such a minor bootstrap feature
is no option for me.

>>No, I still think the LILO method is a good idea.

>Advantage: No FS code.
>Disadvantages: Very careful installation of a new kernel.  One can only
>choose from a limited set of kernels.  (Which is usually enough, of
>course.)

>Let me describe my bootstrap system, the "Minix Boot Monitor", so that
>you can compare its features with LILO yourself.

>A bootable Minix file system contains a bootstrap in the first sector of
>the 1k boot block.  This bootstrap loads and starts the program /boot
>using disk addresses patched into its code by the installboot program.

>/boot (let's call it "the monitor") reads the second sector of the boot
>block, the so called "parameters sector" to configure itself.  (There
>are no config files whatsoever, it is all in this parameters sector.)

>The monitor interprets a shell like language that has variables, simple
>functions, menu items, and commands like 'boot', 'delay', 'ls', etc.
>It can read commands from the keyboard, but normally begins by executing
>the function 'main'.  Main by default runs 'menu'.  The menu by default
>shows one choice:  "Start Minix".  This "choice" runs the command 'boot'
>with no arguments.

>The boot command selects the newest kernel image from the directory
>/minix, loads and starts it bringing up Minix.  (You know, Minix, "the
>early Linux development system."  :-)  )

>If I wanted to run an old kernel I would hit ESC to get to the monitor
>prompt and type:

>       >ls /minix                      (The > is the monitor prompt)
>       /minix/1.6.25.1r178             (Blame 'uname -rv' for the names)
>       /minix/1.6.25.1r188
>       >image = /minix/1.6.25.1r178
>       >boot

>Knowing the filesystem allows for a nice 'ls' command to look around on
>the boot device.

>To configure my system at home I have typed:

>       >rootdev = sd2a                 (Use /dev/sd2a as the root device,
>                                       not the default RAM disk)

>       >main() {trap 2000 boot; menu}
>                                       (Install a 2 second trap to run the
>                                       command 'boot', then show the menu)

>       >minix(=,Minix-386vm) {boot}
>                                       (Add a menu entry for the '=' key)

>       >dos(d,MS-DOS) {boot hd1}       (A menu entry to boot DOS)

>       >SERIAL3 = on                   (Enable /dev/tty03, aka COM4)
>       >DPETH0 = :15:                  (Ethernet 0 is at IRQ 15 instead of
>                                       the default)
>       >console = 2A:100:40            (Use BIOS mode 2A for 100x40 text)

>       >save                           (Save current settings)

>If I turn on my machine I see this:

>       Minix boot monitor 1.6

>       Press ESC to enter the monitor

>       Hit a key as follows:

>           =  Minix-386vm
>           d  MS-DOS

>I have got two seconds to type 'd' before it starts Minix automatically.

>Further notes:

>The monitor doesn't know what sd2a is, it simply looks up /dev/sd2a in
>the file system to find its device number.  The device number is handed
>to the kernel.  One more advantage to know what the FS looks like.

>Choosing the newest kernel from a directory is another advantage of
>knowing the FS.  The monitor can search directories and look at dates.
>I can simply throw a newer kernel image into /minix and delete one of
>the older images.

Hmm, what about running the install programm in /etc/rc.d/rc.[0K] ?

        Joern Rennecke

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

From: [email-masked] (Albert D. Cahalan)
Subject: Re: Alpha Linux
Date: 06 Sep 1994 16:38:15 GMT

   >|> Alpha is making everything 64 bit clean and this will apply to the EISA
   >|> drivers.

   >Only if Linux on the Alpha will be a 64-bit-OS. 

   I sure hope it will be. Who wants a 32 bit OS on an Alpha?

   >If it will be, I hope
   >that they do not repeat the OSF/1 idiocy of having only 32-bit ints.

   Then you have to drop either the 16 bit or the 32 bit int type. Both
   options may make some people unhappy. The 32 bit int is a reasonable
   compromise. It also breaks all those programs which assume that a
   pointer and an int are just the same thing, which is a good thing IMHO.

Why drop one? 
16 bits = short int
32 bits = int
64 bits = long
--

Albert Cahalan
[email-masked]

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

From: [email-masked] (Richard L. Goerwitz)
Subject: Americans vs. Europeans (was Re: Unicode...)
Reply-To: [email-masked]
Date: Tue, 6 Sep 1994 15:57:19 GMT

[email-masked] (Alan Cox) writes:

>>Finally, do the display drivers and GUIs support multiple wordwrap
>>directions?
>
>X windows does. Its fair to say its not exactly used a lot but X can do it.

Thanks for a thoughtful posting.  This one part I'm not sure is right.
X doesn't know anything about text.  It's the anciliary libraries that
take care of that.  So the question is what widget sets support non-
western languages and alternate wordwraps (as well as bidirectional word-
wrap, which for left-right/right-left languages has established typo-
graphical conventions).  Do you really know of any that do this well?

>>Am I babbling nonsense, or am I making sense?
>
>You are raising issues that most people don't care about or need, but which
>I suspect you are right in believing will matter some day.

I see what you mean.  This is the attitude many Americans take to their
European counterparts - the thing that so annoys Europeans:  The idea
that scripts or coding schemes other than the ones used here in the US
are unimportant, or at best left to the locals to worry about.

I wonder how many US programmers even today know not to do things like
use 'a' in place of decimal 97.  ANSI C uses setlocale to change the com-
piler's interpretation of what 'a', etc. mean.  Again, I don't pretend
to be a guru or anything.  I just want to emphasize that if Linux is to
"take off" as a worldwide OS, US programmers involved in its creation
need to think more globally than they might have been inclined to do in
the past.  Linux doesn't carry the same baggage that other Unixes do, &
there exists a marvellous opportunity here for globalization.

The same remarks applied to US programmers re Europeans, BTW, may be
applied to Europeans vis-a-vis the rest of the world (i.e. the majority
of the world - which speaks languages like Urdu, Chinese, Arabic, etc.).
No fair pointing fingers at Americans, while comitting the same sins 
as us :-).

-- 

   -Richard L. Goerwitz              [email-masked]
   [email-masked]          rutgers!oddjob!ellis!goer

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

From: [email-masked] (John McClary Prevost)
Subject: Re: Kernel change summary 1.1.45 -> 1.1.46
Date: 6 Sep 1994 17:36:35 GMT

Brad Midgley ([email-masked]) wrote:
: In article <[email-masked]>,
: John McClary Prevost <[email-masked]> wrote:

: [multi-user mode changing of append-only/imutable bits]

: >Hmm.  Doesn't this decrease the usefulness of the append-only and
: >immutable bits?  As I understood it, the rational for adding these
: >attributes was to make it harder for would-be system crackers to do
: >serious damage or remove traces of their work.  (i.e., they break in,
: >hack root, try to remove entries from /var/adm/syslog, and discover
: >that they have to be in single user mode to do anything except append
: >to it.)

: For this purpose, the raw device must also be immutable.  But what
: about mknod?  How would mknod know which created-devices should be
: immutable?  a root break-in could do anything he wanted to the file
: system with access a writable raw device (albeit difficult).

: Disallowing mknod exept in single-user mode would be overkill.

I think the difficulty is the main idea...  No system can be totally
secure, only very very hard to break into.  If a cracker has utilities
to work with the raw disk and frob the immutable bits, or is able
to patch up the syslog by hand on the raw device, there's really not
anything you can do to stop them once they get to root.  I suppose
anyone who's really intent on hacking root and not leaving a trace
will do this...  But they could get burned the first time.

In any case, the immutable and read-only aren't all that useful yet,
except that it's a read-only flag that effects even root, kind of
an idiot-proof setup.  I hope that the idea is expanded upon, though.

--
@-`-,-- John McClary Prevost
        Systems Programmer, CS Facilities, Carnegie Mellon University

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

** 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.development) 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-Development Digest
******************************