Linux-Development-Sys Digest #639, Volume #6     Wed, 21 Apr 99 02:14:23 EDT

Contents:
  EXT2 Sponsor File system ("JohnDOe")
  I Need Help With LILO Boot Manager!!! (Craig Christensen)
  Re: ncurses: detecting ALT key?? ("David Peavey")
  Re: Trusted Linux (Peter Samuelson)
  Re: Linux installation on Generic box (Alastair)
  high resolution timer & SMP (Jean-Marie Sulmont)
  Maximum number of processes (David Wiener)
  Re: 2.2 kernel, diskless clients, chicken/egg problem ? (Tom Daley)
  Re: Diferences to other UNIXes ("G. Sumner Hayes")
  Re: what is rpm? ("G. Sumner Hayes")
  Re: Kernel debugging over serial port ("Paul Fulghum")
  Re: Timer Function in Linux? (Michael Hirsch)
  Re: "Permission denied" (Peter Samuelson)
  Problems getting APM to work with 2.2.5 ("Eric")
  Re: Trusted Linux ("G. Sumner Hayes")

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

From: "JohnDOe" <[EMAIL PROTECTED]>
Subject: EXT2 Sponsor File system
Date: Tue, 20 Apr 1999 19:17:23 +0200

Hello

I am modifying the linux ext2 file system to become a sponsor file system as
part of a project for my education.

Project profile:

Entries in directories can be kept alive by "sponsoring" them.
Entries can be sponsored through one or more "accounts".
Entries without sponsor money left will be removed.
Examine the links with the quota system (size limits).

We want to charge processes/users for the disk space they use. But unlike
the quota file system which works at the level of "file owner", we want to
enable arbitrary processes to "sponsor" a file even they do not own it. For
this, each process(user) has a default account. Newly created files are
linked to this account. Periodically, we debit some size-dependent "disk
tax" to the account. If there is no money left, the file is removed. Third
party processes can sponsor a file by attaching their account to the file.
So even when the creator's account has no money left, others may enable the
file to persist.

For more information visit this page:
http://www.docs.uu.se/~tschudin/lect/19981999/ds1/proj/e3.html

Or my project homepage:
http://www.docs.uu.se/~it97ern/sponsorfs/

If anyone has got any experience of similar projects or programming
involving things like this, please contact me. I would appriciate any help,
since I am not too good either in C or the linux sources... (well I get
by...)

I am especially interested in any information concerning modifying the
rec_len in the ext2's directory structure, since that probably will be part
of the implementation of our sponsor file system.

/Erik Nordstr�m
[EMAIL PROTECTED]






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

From: Craig Christensen <[EMAIL PROTECTED]>
Subject: I Need Help With LILO Boot Manager!!!
Date: Mon, 19 Apr 1999 17:00:35 -0400

I am using RedHat 5.2 and I am trying to utilize LILO.  I had installed
LILO into the "/boot" directory instead of the Master Boot Record (MBR)
because I was going to use Partition Magic to boot to Windows95 and
LINUX.  That didn't work so I want to place LILO in my MBR so that I can

boot to Window95 and LINUX.

How do I place LILO in my MBR without re-installing Redhat LINUX 5.2?

Craig Christensen
[EMAIL PROTECTED]


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

From: "David Peavey" <[EMAIL PROTECTED]>
Subject: Re: ncurses: detecting ALT key??
Date: Mon, 19 Apr 1999 14:18:53 -0700

Perhaps this web page can help.
http://stekt.oulu.fi/~tosi/kbd/kbd.html

Dan Miller wrote in message <7fftoo$[EMAIL PROTECTED]>...
>Is there some way I can detect that the ALT key is pressed??  When I use
>getch(), Alt-<key> seems to return the same as <key> in most cases...
>I don't see any functions in ncurses for separately testing the state
>keys...
>???
>
>        Dan Miller
>
>
>



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

From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Trusted Linux
Date: 19 Apr 1999 16:48:58 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>

[Des Herriott <[EMAIL PROTECTED]>]
> Coincidentally, I've been looking through the kernel source recently,
> and came across these capabilities.  I'm pretty much a newbie when it
> comes to the kernel, but I'm guessing that capabilities could allow,
> for example, a non-root user to be given privileges to bind to a
> specific port?  For example, give the 'www' user privileges to bind
> to port 80/443/whatever.

Yes, almost.  There is a capability (CAP_NET_BIND_SERVICE, see
<linux/capability.h>) to allow you to bind to any port below 1024, but
anything more specific would be hard to do.  To understand this,
realize that capabilities are implemented as a bitmask: each one is a
bit that can be set or cleared somewhere in the process structure.  You
do *not* want to have 1024 bits taken up by port binding.

In practice, allowing a process to bind to ports below 1024 should be
sufficient: I can't think of any easy way for a rogue program (or code
running itself out of an overrun buffer) to take advantage of this to
gain more privileges.  Compared to Almighty Root, the cracker would not
be very powerful....

> I ask because I've been wondering why this hasn't been done before in
> Unix - I gather that trusted version of certain Unices have allowed
> it, but it seems like such a generally useful security addition that
> it's surprising it hasn't been seen more widely.

Since <linux/capability.h> references POSIX, I think we can assume this
is a POSIX standard of some sort.

> Am I right in supposing that capabilities could be used for this
> purpose?  And perhaps configurable via a /proc interface?

What's to configure?  There just needs to be some easy way for a
process to get a specific set of capabilities.  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.)

-- 
Peter Samuelson
<sampo.creighton.edu!psamuels>

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

From: [EMAIL PROTECTED] (Alastair)
Crossposted-To: 
comp.os.linux.help,comp.os.linux.setup,comp.os.linux.hardware,comp.os.linux.development.apps,redhat.hardware.arch.intel,alt.os.linux,alt.uu.comp.os.linux.questions,linux.redhat,comp.os.linux.questions,comp.os.linux.networking,alt.linux,aus.computers.linux,comp.os.linux.advocacy,linux.redhat.install,comp.os.linux.x,comp.os.linux.prog,comp.os.linux.m68k
Subject: Re: Linux installation on Generic box
Date: Wed, 21 Apr 1999 00:10:32 GMT
Reply-To: [EMAIL PROTECTED]

Alex Balboa (HPTi|crimmins) <balboa> <[EMAIL PROTECTED]> wrote:
>
>--------------B1F23E745D52B5CDCF4FC646
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit

Plain text please. That was a very badly formatted post.

>I am currently trying to install Redhat 5.2 Linux on the following
>system configuration:
>System board brand: Tyan ATX S16820 Tahoe 2 ATX (Pentium II PCI ATX)
>CPU: Pentium II 266 MHZ (dual) with 512 K of cache)

Followups set to : comp.os.linux.hardware

You could also try dejanews (http://www.dejanews.com/home_ps.shtml).



-- 

Alastair
work  : [EMAIL PROTECTED]
home  : [EMAIL PROTECTED]

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

From: Jean-Marie Sulmont <[EMAIL PROTECTED]>
Subject: high resolution timer & SMP
Date: Mon, 19 Apr 1999 14:58:56 -0700
Reply-To: [EMAIL PROTECTED]

ICAgKiBBbnlvbmUgY2FuIHRlbGwgbWUgd2hlcmUgKGlmKSBJIGNhbiBmaW5kIGEgaGlnaCBy
ZXNvbHV0aW9uIHRpbWVyIGFzDQogICAgIHRoZSBnZXRocnRpbWUoKSBmcm9tIHRoZSBTb2xh
cmlzIGxpYmMuIEFsdGhvdWdoIGdldHRpbWVvZmRheSgpIGlzIGENCiAgICAgY2hlYXAgc3lz
dGVtIGNhbGwsIDEuNiBtaWNyb3NlY29uZHMgYW5kIGEgY29udGV4dCBzd2l0Y2ggYXJlIHN0
aWxsDQogICAgIGEgbG90IGNvbXBhcmVkIHRvIGdldGhydGltZSgpIG9uIFNvbGFyaXMuICBP
ZiBjb3Vyc2UsIHNpbmdsZSBDUFUNCiAgICAgYm94ZXMgbWF5IHVzZSB0cmlja3MgYXMgdGhl
IHJkdHNjIHBlbnRpdW0gaW5zdHJ1Y3Rpb24gYnV0IHRoZW4gdGhlDQogICAgIHByb2JsZW0g
aXMgdG8gcmVsYXRlIHRoZSBudW1iZXIgb2YgQ1BVIHRpY2tzIHJlcG9ydGVkIHRvIHRoZSBj
bG9jaw0KICAgICBzcGVlZCBpLmUuIGdvIHJlYWQgdGhlIGJvZ29taXBzIGZyb20gL3Byb2Mg
b3IgY29tcHV0ZSBzb21lDQogICAgIGVxdWl2YWxlbnQuIFRoaXMgaXMgbm90IGEgdmlhYmxl
IHNvbHV0aW9uIG9uIFNNUCBzaW5jZSB0aGVyZSBpcyBubw0KICAgICBndWFyYW50eSB0aGF0
IHRoZSBDUFVzIGFyZSBib290ZWQgYXQgdGhlIHNhbWUgdGltZS4gICBJdCB3b3VsZCBiZQ0K
ICAgICBjb29sIHRvIGhhdmUgdGhpcyBjb3VudGVyIGtlcHQgY29uc2lzdGVudCBhY3Jvc3Mg
Q1BVcyBieSB0aGUga2VybmVsDQogICAgIGFuZCBtbWFwZWQgYnkgZXZlcnkgc3RhcnRpbmcg
cHJvY2VzcyB0aHVzIGF2b2lkaW5nIGEgc3lzdGVtDQogICAgIGNhbGwuICAgICAgICBXZWxs
IEkgYW0gcmVhZHkgdG8gcHV0IHNvbWUgZW5lcmd5IGluIHRoaXMuLi4NCiAgICogV2hhdCdz
IHRoZSBzdGF0dXMgb2YgTGludXggaW4gcmVzcGVjdCB0byB0aHJlYWRzPyBMaW51eHRocmVh
ZA0KICAgICAoWC5MZXJveSkgc2VlbXMgdG8gYmUgYWRvcHRlZCBidXQgSSBoYXZlbid0IHNl
ZW4gYW55IGRpc2N1c3Npb24gb24NCiAgICAgdGhlIG1vZGVsIGl0IGltcGxpZXMgKHVzYWdl
IG9mIGNsb25lKSB2ZXJzdXMgc29tZSBMV1Agb3Igb3RoZXJzDQogICAgIHByb3MgZXQgY29u
dHJhcy4NCg0KVGhhbmsgeW91Lg0KDQotLS0NCmplYW4tbWFyaWUgc3VsbW9udCAgICAgICAg
ICAgICAgICAgICAgICAxMDAwIFNXIEJyb2Fkd2F5ICBzdWl0ZSAxMjAwDQpzb2Z0d2FyZSBl
bmdpbmVlciAgICAgICAgICAgICAgICAgICAgICAgUG9ydGxhbmQgT3JlZ29uLCA5NzIwNQ0K
T3JhY2xlIENvcnBvcmF0aW9uICAgICAgICAgICAgICAgICAgICAgIFBob25lOiAoNTAzKSA1
MjUtODA1Nw0KanN1bG1vbnRAdXMub3JhY2xlLmNvbSAgICAgICAgICAgICAgICAgIEZheDog
ICAoNTAzKSA1MjUtODAwMA0KDQoNCg==

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

From: David Wiener <[EMAIL PROTECTED]>
Subject: Maximum number of processes
Date: Mon, 19 Apr 1999 14:39:18 -0700

Hi

We're running a D3 database on Linux 2.0.36 (RH 5.2) which interfaces
with the users via telnet, ODBC, and web/cgi.  We've recently added more
users and started to experience problems with starting new processes,
etc.

Question:   Is there a finite number of processes that can be run?  And
if so, can this be controlled via some paramater?  And...if we turn up
the number of processess, what is the cost?

Many thanks in advanace.


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

From: [EMAIL PROTECTED] (Tom Daley)
Subject: Re: 2.2 kernel, diskless clients, chicken/egg problem ?
Date: 19 Apr 1999 22:05:01 GMT

In article <[EMAIL PROTECTED]>,
        Fred Jolly <[EMAIL PROTECTED]> writes:
> Nils Ulltveit-Moe wrote :
>> Have anyone managed to make NFS-root work on diskless clients running
>> a 2.2 kernel?
> [snip ...]
>>Looking up port of RPC 100003/2 on 193.180.211.70
>> RPC: sendmsg returned error 101
> 
> I've the same problem.

I have the same problem as well.  Haven't figured it out yet.
Is there more that needs to be running (like portmapper) before 
the mount -a ?  I can boot NFS if the client is 2.0 and the server
is 2.2.  So the problem is on the client end I think.

-- 
===================================================================
|         o    Tom Daley                                          |
|   ___ </v    Woodland Park, CO                                  |
|  ___  -\     [EMAIL PROTECTED]                                |
| ___    /                                    (719) 534-0449  x27 |
|       (*)    Linux!                                             |
===================================================================


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

From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: Diferences to other UNIXes
Date: Tue, 20 Apr 1999 21:22:18 -0400

Thomas Pfrengle wrote:
> I should do some development for a SGI. As a SGI is too expensive for
> us, we thought to do the development on LINUX and do the integration 
> on SGI.
> 
> Can anybody tell me, if I have to exspect problems. Especially, does
> LINUX support shared memory-IPC ??

Linux supports SysV IPC and mmap with the MAP_SHARED flag.  It does
not yet support POSIX shm (to the best of my knowledge).  It does not
support anonymous shared mmap.  If you need to use some facility that
isn't supported, it is easy to write a little SHM wrapper that uses
e.g. mmap on Linux and POSIX shm on another platform.

Note that on many SGIs, the default X visual is not the best one -- this
is not generally the case on Linux machines, so if your X code works on
Linux and fails on the SGI this is a place to check.

As long as you're reasonably careful about avoiding linux-specific
interfaces (sendfile, /dev/random, SO_PEERCRED, etc) you shouldn't
have any problems.  I've done Linux development for eventual SGI
deployment successfully.  If possible, test on an SGI machine 
periodically to work out the kinks.

The suggestion to use autoconf is a good one if you're expecting to
maintain the code for very long or may want to use it on other Unices
in the future.

--Sumner

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

From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Crossposted-To: tw.bbs.comp.linux
Subject: Re: what is rpm?
Date: Tue, 20 Apr 1999 21:26:59 -0400

Enosh Chang wrote:
> 
> Could somebody tell me what is RPM, and how to use it? Is it another
> compress file format?

It's a redhat package manager file.  Use "rpm -Uvh" to install one on
a Redhat machine (or other rpm-using machine).  Use rpm2cpio to convert
it to a regular cpio archive.  If you don't have rpm2cpio, the rpm is
just a cpio file with a header on it -- check through the last couple
of weeks on linux-kernel to find a perl script that pulls the cpio file
out.  (Of course, use cpio -id to extract a cpio archive).

If it's a source RPM, use rpm --rebuild to build a binary rpm and
install that.  "man rpm" or "rpm --help" for more info.

On debian or slackware, you could use alien to import rpm files to the
native package format.  I don't know how current the Slackware support
is.

--Sumner

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

From: "Paul Fulghum" <[EMAIL PROTECTED]>
Subject: Re: Kernel debugging over serial port
Date: Wed, 21 Apr 1999 01:39:42 GMT

It works fine on intel, get gdbstub from:

http://www.gcom.com/#linux

--
Paul Fulghum
[EMAIL PROTECTED]

Chet Douglas <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I am looking into the possibilities of doing remote kernel debugging
> over the serial port using gdb.  I am running the 2.2.6 kernel and have
> heard rumors that remote debugging does not currently work on the i386
> platform.   Can anyone substantiate this?
>
> Thanks,
> Chet
>
> --
> Chet Douglas
> CRD Consulting - Custom Device Drivers and Software
> [EMAIL PROTECTED]
> http://www.crdconsulting.com
> (520) 432 4359




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

From: Michael Hirsch <[EMAIL PROTECTED]>
Subject: Re: Timer Function in Linux?
Date: 20 Apr 1999 23:35:04 -0400

Gerard van der Sel <[EMAIL PROTECTED]> writes:

> I have a question about RTC on linux. The only thing I could find was
> that it is necessary every 11 minutes, when you have installed a 'DFC'
> (atomic radio clock) board on your PC. Is there an other use for this
> device?

To run win98 under vmware well you need the RTC.  Without it the mouse
pauses around once a second for no apparent reason.

-- 
Michael D. Hirsch                       Work: (404) 727-7940
Emory University, Atlanta, GA 30322     FAX: (404) 727-5611
email:  [EMAIL PROTECTED]         http://www.mathcs.emory.edu/~hirsch/

Public key for encrypted mail available upon request (or finger
[EMAIL PROTECTED]).

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

From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: "Permission denied"
Date: 20 Apr 1999 23:15:26 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>

[Bill Zimmerly <[EMAIL PROTECTED]>]
> Although at this moment, since I spent most of last night
> reinstalling everything, I do want to know how I can, as you put it,
> "check to make sure inetd really is running as root".

I don't remember if you said which distribution you were running
... anyway, for Debian, the pid file is in /var/run, so:

  ps u `cat /var/run/inetd.pid`

Possibly this would work with e.g. Red Hat, but I don't know.

-- 
Peter Samuelson
<sampo.creighton.edu!psamuels>


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

From: "Eric" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.misc,comp.os.linux.setup
Subject: Problems getting APM to work with 2.2.5
Date: Wed, 21 Apr 1999 04:30:00 GMT

I've recently tried upgrading to Kernel 2.2.5, but am running into a couple
of problems.  I'm running RH5.0, with all the upgrades as per the 2.2
changes doc.


My is with the APM.  I am upgrading from 2.0.32.  I'm running
this on a PII (ATX motherboard), but for some reason, the "poweroff on
shutdown" feature doesn't work with 2.2.5.  Under kernel 2.0.32, it would
automatically poweroff my PC, but 2.2.5 just displays the "System halted"
message.  The system is running on an Asus P2B motherboard.  Are there any
special things I have to do to get 2.2.5 to auto-powerdown the system?

I've installed the new syslogd and klog daemons, as well as the new sysvinit
toolkit (which has the new halt -p functionality, etc), but they don't seem
to make any differences.

Does anyone know what I can check or do to get my PC to auto-power-off upon
a halt -p or a shutdown -h command?

Thanks!

Eric
[EMAIL PROTECTED]





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

From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: Trusted Linux
Date: Tue, 20 Apr 1999 21:12:35 -0400

Peter Samuelson wrote:
> 
> > I ask because I've been wondering why this hasn't been done before 
> > in Unix - I gather that trusted version of certain Unices have 
> > allowed it, but it seems like such a generally useful security 
> > addition that it's surprising it hasn't been seen more widely.

1. It raises some nasty compatibility issues -- see the ongoing flames
on linux-kernel.  Even utilities like tar and cp may need to be
modified depending on what approach is used.  This is a good thing
from a security perspective and a bad thing from a usability/ease of
migration perspective.
2. It's a bit tricky to administer properly.
3. People don't care -- look at all the people who surf the 'net in
Netscape as root with Java/Javascript enabled.
4. It's tough to get right -- the bigger and more complex your system,
the more ways for it to go wrong.  A less general "trusted" variant
makes it easier to audit the system.

Low demand == not lucrative without a high price tag == better off in
a seperate, trusted, expensive product.  If you have the source, some
of those arguments may not apply in the same way.  Witness the Linux
capability patches (and I think Terry Lambert has something for FreeBSD,
unsure as to the status...)

> Since <linux/capability.h> references POSIX, I think we can assume 
> this is a POSIX standard of some sort.

Nope.  It was part of POSIX 1003.1e (and userspace in
1003.2c), which was withdrawn -- never standardized.

posix1e at cyrus dot watson dot org is a mailing list discussing
possible implementations of these standards -- Rik Riel (Linux kernel
hacker) is on the list, as are some FreeBSD folk and one of the former
editors of the POSIX draft before it was withdrawn.  
 
> > Am I right in supposing that capabilities could be used for this
> > purpose?  And perhaps configurable via a /proc interface?
> 
> What's to configure?  There just needs to be some easy way for a
> process to get a specific set of capabilities.  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.)

Of course, if you read the flamefest on linux-kernel these are
exactly the options being discussed.  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:

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
special knowledge of every binary format (beyond magic numbers) is
gross, and with some formats this just isn't possible.
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.
3. It is grossly inefficient even given the performance limitations of 
capability lists.
4. It requires violating the ELF specification to interoperate
securely with older kernels.
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.
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.  This
is a case where not only is userspace broken, but it's nearly impossible
to fix it even when you know what the problem is.  Plus, it's the very
tools that are most important in responding to security compromises
that are busted -- not a good tack to take when implementing security
features.

Proponents of this solution often see #5 as a feature, for some reason.

An in-fs solution breaks NFS, but that's not a big deal -- you need to
have a precise list of your priviledged bins anyway, so you could copy
them and set the priv bits at boot time.  Especially wise given that
NFS isn't secure anyway -- allowing priviledged binaries from NFS
mounts, even if it were possible, would be stupid.  Much better to
copy them, verify hashes/signatures against a trusted list, and only
then grant privs.  I don't know about the impact on AFS/Coda; I never
had a chance to worry about distributed setuid bins when I was at an
AFS-using institution (thank god).

--Sumner

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


** 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
******************************

Reply via email to