Linux-Development-Sys Digest #646, Volume #6 Thu, 22 Apr 99 21:14:07 EDT
Contents:
Question: rewrite fdisk to preserve a file? ([EMAIL PROTECTED])
Re: Trusted Linux (James Youngman)
Re: compiling 2.2.x with egcs and libc.so.5.4.44 (Piniek aka Piotr Ingling)
kmem_alloc: Bad Slab Magic problem in 2.2.6 (David Ronis)
Re: Question: hacking fdisk to preserve a file? (Tin Siladin)
Re: Help - Installing module for new kernel (Martin Wilhelm)
Re: using mmap for PCI device memory ("jeff")
The UNIX GUI Manifesto ("Jethro Wright III")
Re: Linux for CompactPCI BUS? ((cosc1 95h02740))
2.2.6 fails in iriap.c (Derek Glidden)
Re: Trusted Linux (Christopher Browne)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Question: rewrite fdisk to preserve a file?
Date: Thu, 22 Apr 1999 19:55:02 GMT
This seems as good a place as any to post this. I've been trying to
brainstorm a way to preserve a single file (say, a tarball) during a system
repartition. (You can see the benefits of this for non-Windows advocates;
doing so would greatly ease installation of new operating systems on systems
without good backup facilities.) Assuming the user has one partition (C:)
and is readable by Linux, I hypothesize this would go as follows:
1) boot up with a linux floppy
2) mount C:
3) have the user select the files on C: to be saved
4) dump these files into blahblah.tgz
5) have the user decide on a partitioning scheme (for example, adding a D:)
6) dd blahblah.tgz to some specific address on the hard disk, an address
which will fall inside D:'s partition
7) change the partition table
8) format C: as DOS; mount C:
9) dd blahblah.tgz back over to C:
10) format D: as DOS; mount D:
11) cp blahblah.tgz to D:
12) reboot with the Windows (or whatever) installer, install onto C:
13) boot from C:, copy blahblah.tgz from D:, unzip them
14) install new OS onto D: at leisure
But surely this is not a novel idea, and would fail for some blatantly obvious
reason. If so, what is that reason? Why wouldn't this work?
--AED
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: James Youngman <[EMAIL PROTECTED]>
Subject: Re: Trusted Linux
Date: 21 Apr 1999 20:52:50 +0100
"G. Sumner Hayes" <[EMAIL PROTECTED]> writes:
> Depends on perspective, I suppose. I may have an important daemon
> that's only available as a SCO binary that needs to bind a low port;
> not having source code, I don't want to give it setuid root status.
No problem. Provide a wrapper which runs with that capability, make
it call setuid() to give away root privs if it has them, and then make
it exec() the real binary.
--
ACTUALLY reachable as @free-lunch.demon.(whitehouse)co.uk:james+usenet
------------------------------
From: [EMAIL PROTECTED] (Piniek aka Piotr Ingling)
Subject: Re: compiling 2.2.x with egcs and libc.so.5.4.44
Date: Thu, 22 Apr 1999 20:54:26 GMT
Reply-To: [EMAIL PROTECTED]
Dnia Thu, 22 Apr 1999 12:46:50 -0400, Jeremy Schofield
<[EMAIL PROTECTED]> napisa�(a):
>Hi,
> I apologize if this topic has been discussed already as
>I have not been following this group for some time.
>I'm unable to compile the new kernel (any 2.2.x) with egcs (version 1.1)
>and the old libc. I get the following error while compiling
>"checksum.c" in the arch/i386/lib subdirectory:
>
>gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
>-fomit-frame-pointer -pipe -fno-strength-reduce -m486 -malign-loops=2
>-malign-jumps=2 -malign-functions=2 -DCPU=686 -c -o checksum.o
>checksum.c
>checksum.c:200: redefinition of `csum_partial_copy'
>checksum.c:105: `csum_partial_copy' previously defined here
>{standard input}: Assembler messages:
>{standard input}:185: Fatal error: Symbol csum_partial_copy already
>defined.
>
[...]
Just delete that file (checksum.c).
Piotr Ingling
e-mail: [EMAIL PROTECTED]
------------------------------
From: David Ronis <[EMAIL PROTECTED]>
Subject: kmem_alloc: Bad Slab Magic problem in 2.2.6
Date: Thu, 22 Apr 1999 16:14:44 GMT
I've been using 2.2.6 on an DELL 133Mhz i586 for a couple of days now,
having upgraded from 2.2.5. Last night, I was running the performance
benchmarks for the latest egcs-CVS codes, when the system crashed.
Nothing was left in the messages, syslog, or debug file; the only
diagnostic was a stream of
kmem_alloc: Bad slab magic (corrupt) (name=skbuff_head_cache)
repeating on the main console. The system wouldn't reboot with
CTRL-ALT-DEL, and after a hardware reboot, I was left with a badly
corrupted disk.
The specific benchmark that was running was testing a highly recursive
function:
testing takeuchi, calculates a highly recursive function,
nice for testing function call overhead
- tak x y z = z, if y >= x
- = tak (tak (x-1) y z) (tak (y - 1) z x)
- (tak (z - 1) x y), otherwise
and has worked in the past. I've set up the shell to have memory
usage unlimited and a maximum stack of 8192K (I have 48Meg of RAM and
32 Meg of swap, so this shouldn't have been an issue). This was the
only user process running on the machine.
Any ideas what went wrong?
David
------------------------------
From: Tin Siladin <[EMAIL PROTECTED]>
Subject: Re: Question: hacking fdisk to preserve a file?
Date: Thu, 22 Apr 1999 16:41:40 -0400
[EMAIL PROTECTED] wrote:
>
> Tell my why this won't work. It seems to me that it should be possible to
> hack fdisk to preserve a single file during a repartitioning. This would
> make partitioning and reformatting of single-drive, backup-less systems (such
> as most home systems) much less painful. I speculate it could be done as
> follows on a system with one C: partition with Windows installed:
>
> 1) boot from a linux floppy (with utilities on it) 2) mount c: 3) dump
> all the files the user want to save into c:/foo.tgz 4) have the user make a
> new partition table (we'll say the user wants to add one new partition, and
> equally split the drive space. foo.tgz is assumed to be small enough to fit
> on either partition) 5) dd foo.tgz to some address on the disk inside what
> will become the d: partition 6) rewrite the partition table 7) format
> the new c: as DOS 8) dd foo.tgz from inside the future d: partition over
> to the c: partition 9) format the new d: as DOS 10) cp foo.tgz from c: to
> d: 11) install windows onto c: 12) boot up from c:, decompress foo.tgz and
> recopy the files 13) install linux or whatever onto d:
>
> There's got to be some reason why this wouldn't work. What is it?
>
> --AED
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
If the entire disk is one partition (C:) to start with, you have to know
which disk blocks c:/foo.tgz occupies in step 3 so you don't overwrite
it in step 5. Look in the LILO source code to see how it finds out disk
block numbers. I boot off ext2, but I'm pretty sure LILO is able to get
a list of file disk blocks from a DOS partition as well.
I'm not even sure you need to hack fdisk for this. A different fdisk is
not
required for any of your steps!!!
Of course that's just my opinion, I may be wrong.
Tin Siladin
CrosStor Software
------------------------------
From: Martin Wilhelm <[EMAIL PROTECTED]>
Subject: Re: Help - Installing module for new kernel
Date: Wed, 21 Apr 1999 21:37:06 +0200
Reply-To: [EMAIL PROTECTED]
Simon Su wrote:
>
> Hello,
> I am using Redhat 5.2 without the update rpm installed at the moment.
> But the same problem exist with the updated rpm. After I successfully
> compile my kernel, I tried to install the modules. When I typed make
> modules_install in the /usr/src/linux directory, it tells me that no *.o
> files found. when I do a ls on the modules directory, there is no
> file(s) there. Is this a problem or did I do something wrong?
>
> Any advise will be greatly appreciated.
Did you have made 'make modules'?
-and-
Have you selected one or more part of the kernel as module
<M>?
Martin
PS:
Sorry for my bad english ;) I try to improove this...
--
martin wilhelm \ thueringen netz e.V. \ cube e.V. (iG)
[EMAIL PROTECTED] \ [EMAIL PROTECTED] \ [EMAIL PROTECTED]
ICQ: 2316518 (selten) \ [EMAIL PROTECTED] \ [EMAIL PROTECTED]
FAX: 089 6661 760496 \ www.thur.de \ www.cube-ev.org
------------------------------
From: "jeff" <[EMAIL PROTECTED]>
Subject: Re: using mmap for PCI device memory
Date: Thu, 22 Apr 1999 15:00:50 -0500
That's great! I did run into a similar problem also.. I believe I changed
the MAP_PRIVATE to MAP_FILE|MAP_SHARE .. seemed to fix the problem.
This should also let you write to the registers.. At least it worked on
mine.
My driver seems to work fine only for the top portion of the registers. I
have a device that has 128 control registers.. I seemed to have only access
to the top half... strange!! I am doing something wrong but I can't seem to
figure it out. I can't seem to rd/wr to the bottom half of the registers..
something in my 'vma' setup is not right..
anyways you may want to try MAP_FILE|MAP_SHARE..
jeff-
Tim Linehan wrote in message <_cHT2.205$[EMAIL PROTECTED]>...
>Jeff,
>
>Actually, just about 5 minutes after I sent this message, I got the mmap
>function to work. You are right, I had to pass the physical address of the
>range I wanted remapped. (I read the section you quote in your message, and
>that sort of set things straight for me).
>
>However, I can read fine from this memory location now, but I cannot write.
>I get a:
>
>do_wp_page: bogus page at address 40008484 (e1000000)
>
>error whenever I try to write to the location. When I call mmap from the
>user space program, I am setting PROT_READ | PROT_WRITE, and MAP_PRIVATE
for
>my prot and flags respectively.
>
>Here's how I call the mmap function from my user space program, if this
>might help you:
>
>register_base = (DWORD) mmap (0, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE,
>file_desc, 0);
>
>This does return an apparently valid address, as I can read OK. I've got
to
>work on the write problem now.
>
>TL
>
>
>
>
------------------------------
From: "Jethro Wright III" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux
Subject: The UNIX GUI Manifesto
Date: Thu, 22 Apr 1999 17:35:44 -0400
Don't know if anyone's interested, but I just did a bit of
compelling reading at: http://www.cybtrans.com/infostrc/unixgui.htm
I DON'T WANT A FLAME WAR, but there are some who might
actually find this bit an interesting take on Unix and GUIs. It
certainly has gotten my attention as someone who's new to Unix
and wants to get into GUI app development in the shortest time
possible....Jet
--
================================================================
In Paris, they simply stared when I spoke to them in French;
I never did succeed in making those idiots understand their
own language. - Mark Twain, The Innocent Abroad,1869
============================================= [EMAIL PROTECTED] ==
------------------------------
From: [EMAIL PROTECTED] ((cosc1) 95h02740)
Subject: Re: Linux for CompactPCI BUS?
Date: 22 Apr 1999 21:37:01 GMT
Bob Hauck ([EMAIL PROTECTED]) wrote:
: In article <7fn6i6$n34$[EMAIL PROTECTED]>,
: [EMAIL PROTECTED] ((cosc1) 95h02740) writes:
: > Does Linux Support Compact PCI bus?
: Yes. Compact PCI is (mostly) just PCI in a different form
: factor. The Compact PCI FAQ says that Linux will work and I
: have talked to at least one board vendor that confirmed this.
: But also AFAICT, Linux does not support the hot swap feature.
: But then, neither do any of the other popular PC operating
: systems.
That is good. It would be fun to build a telco Central Office
or Mobile Switch on Linux. But hot swapable is definitely a
desired feature, and RealTime Linux is also helpful.
: While I'm posting...does anybody know what work is being done
: regarding CPCI or VME hot swap support? We're looking at doing
: some embedded projects and Linux would fit in real well if it had
: this. I might even be convinced to help 8-)
: --
: 13:45:00 up 58 days, 3:07, 0 users, load average: 0.00, 0.00, 0.00
------------------------------
From: Derek Glidden <[EMAIL PROTECTED]>
Subject: 2.2.6 fails in iriap.c
Date: Thu, 22 Apr 1999 18:39:51 +0000
In trying to compile the 2.2.6 kernel, making the IRDA drivers fails,
unable to find a "linux/irda.h" header. Solutions?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Derek Glidden http://www.illusionary.com/
http://3dlinux.org/ http://www.tbcpc.org/
Web development, database, graphics and general plumbing
Linux, FreeBSD, Apache, MySQL, PostgreSQL, PHP (Say No to NT!)
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: Trusted Linux
Reply-To: [EMAIL PROTECTED]
Date: Fri, 23 Apr 1999 00:12:17 GMT
On 21 Apr 1999 00:34:13 -0500, Peter Samuelson
> <[EMAIL PROTECTED]> wrote:
> [me]
>> > Three possibilities spring to mind: (1) the binary runs as root,
>> > and immediately uses cap_set() to throw away the capabilities it
>> > doesn't use, (2) if a binary is setuid root, the kernel checks
>> > something like an ELF section to see what capabilities to give it,
>> > or (3) specific filesystem support for a capabilities bitmask to go
>> > along with the setuid/setgid bits. Solution #1 is possible already;
>> > I'd like to see #2 implemented in the kernel (and in binutils of
>> > course), and #3 would be very messy. (Think NFS.)
>[G. Sumner Hayes <[EMAIL PROTECTED]>]
>> Of course, if you read the flamefest on linux-kernel these are
>> exactly the options being discussed.
>
>Nice to hear that other people thought of the same ones.
#3 has the *major* problem that it doesn't "inherit" the functionality
across filesystems. "Think NFS" combines with "Gonna have to rewrite
cpio, tar, RPM, dpkg, and anything else that tries to do global things
with files" to give ample quantities of major problems. I think that
kills it as an idea.
#1 only pushes the details into setuid programs, which is certainly a
whole lot "less bad," since care must always be taken with setuid
programs anyways. It has two "bad things":
a) Programs must be modified to use cap_set(). If a program isn't
rewritten to use it, then the program will get "too many
capabilities," thus making the scheme somewhat useless.
b) It makes these programs Linux-specific. Arguably a bad thing.
I quite like #2, as it lets the scheme function reasonably well
whether capabilities are there or not, and more cleanly separates out
the "capability setting." A common utility could be used to set
capabilities, which means that if there's a "bug" in the security
configuration, recoding isn't necessary, but merely some process to
"fix the capability database."
The URL
<http://x16.dejanews.com/[ST_rn=ps]/getdoc.xp?AN=435914490.1&CONTEXT=923406353.1141047422&hitnum=0>
describes a scheme for managing ACL-like information in a "database
file" that is kept separate from the files; my thinking is that
something like this, changed to represent capability attributes, might
be a decent way to go.
>> I don't think #2 is worth implementing (and FWIW Ted T'so and other
>> bigwigs seem to agree) because of a number of elegance, security, and
>> simplicity problems:
>
>I understand it would have drawbacks.
>
>> 1. It only works for some types of binaries -- ELF is okay, but
>> a.out, coff, and other formats are still used by many people. I
>> don't see it as a given that ELF will never be supplanted, either.
>
>Requiring capability binaries to be ELF is not too much more to ask
>than, say, requiring that they be on a particular type of filesystem.
The "TOPS ACL" approach sticks the capability information in a
separate file. This unfortunately means that the kernel becomes
dependent on the contents of a file that is separate from the kernel.
I don't know how bad that is. I suspect that it's better than the ELF
assumption.
>> 2. It requires overloading the meanings of either suid or sticky bits
>> and violating the principle of least surprise WRT said bits -- either
>> a program that is setuid root doesn't really run with UID root
>> (breaks some security scanning programs and people), or the sticky
>> bit is suddenly priviledged (breaks emacs and others, plus NFS
>> mounts), or requires immutability and other bizarre,
>> semantic-breaking features.
>
>Using the sticky bit or immutability bit would be sick and wrong, but
>only checking caps on `setuid root' would not pose so much of a
>problem. After all the process is now getting *fewer* privileges than
>it looks like, not more. So yes it violates the PLS but not too much.
I agree.
>> 3. It is grossly inefficient even given the performance limitations
>> of capability lists.
>
>Oh, not really. Checking the capability mask for a setuid root binary
>wouldn't add much to what exec() has to do. Setting the capabilities
>for the new process takes almost no time. And the kernel has already
>had to parse the ELF headers so finding the cap mask wouldn't be very
>expensive.
Doubtless putting capability information in a separate file would
provide some new race conditions/possible exploits; I don't think that
either of these approaches are "grossly inefficient."
>> 4. It requires violating the ELF specification to interoperate
>> securely with older kernels.
>
>The new binary would run setuid root on an older kernel, which is
>pretty much the situation we already have. In any case, the way I
>understand ELF it would not have violate it at all.
If you ain't got capabilities, then programs will get "too many
privileges." I don't know of a good way around that.
>> 5. It poses a security risk by transfering capabilities without
>> tool-specific knowledge -- cp and tar will happily move priviledged
>> binaries around without warning you.
>
>Oh, no. Tools would be well aware that they were playing with files
>that were marked setuid root. In that regard it's the status quo.
Agreed.
>> 6. It completely breaks tripwire and other intrusion-detection
>> programs and makes them nearly impossible to implement without
>> putting a ton of knowledge about various binary formats into each
>> such tool.
>
>Presumably tripwire et al already check for things that are setuid
>root. So ... they would continue checking for things that are setuid
>root. It would *not* be difficult to write a short utility that could
>set and show cap masks for a file, and any libbfd hacking crap would be
>confined to that program. (A glorified `ls -l' + `chmod u+s', if you
>will.) tripwire would use it, the sysadmin himself would use it, and
>most tools would ignore the issue and treat cap-binaries as normal
>setuid root, etc.
Intrusion detection software tends to be paranoid, no? The result of
capabilities is that some things they may worry about may not be
problems.
>> An in-fs solution breaks NFS, but that's not a big deal
>
>It also breaks fs compatibility with older kernels. That *is* a big
>deal. It is conceptually cleaner, but in practice a lot of userspace
>would need patches. (The same sorts of patches you need when you start
>putting ACL's in the filesystems. Perhaps both ideas should be
>implemented as one big fs interface change.)
If you need to redesign cpio, tar, rpm, dpkg, install, and lots of
other basic file utilities to be ACL-aware, this is a big deal.
If there's *no* networked filesystem that supports the ACL scheme, as
seems to be the case, this is a big deal.
--
"And 1.1.81 is officially BugFree(tm), so if you receive any bug
reports on it, you know they are just evil lies." (By Linus Torvalds)
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
** 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 PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
