Linux-Development-Sys Digest #94, Volume #7 Mon, 23 Aug 99 19:14:13 EDT
Contents:
Re: TAO: the ultimate OS ("Christopher R. Thompson")
Re: PROPOSAL: A secure, simple NIS replacement (Jonathan Abbey)
Re: Can't compile network drivers (Stephen Torri)
Telnet problem (Tranceport)
Re: why does root need supplementary groups? (Phil Howard)
Re: PROPOSAL: A secure, simple NIS replacement (Tuomo Pyhala)
Re: gdb trace of GUI apps core dumping on printf's (Benjamin Audy)
Re: Shared Libraries: what is the linux equivalent of "dllimport" and "dllexport"
(Jonas Utterstrom)
Re: Jesus: the ultimate OS ("Christopher R. Thompson")
Re: TAO: the ultimate OS (void)
Re: Netgear FA310TX ("Marshall")
Re: Setting LD_LIBRARY_PATH from makefile (Peter Samuelson)
Re: Shared Libraries: what is the linux equivalent of "dllimport" and "dllexport"
(Jonas Utterstrom)
Re: Volunteer: Device Drivers!!! (Marinos J. Yannikos)
----------------------------------------------------------------------------
From: "Christopher R. Thompson" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Mon, 23 Aug 1999 12:33:05 -0700
Vladimir Z. Nuri wrote:
>
> an HTML version of this article can be found at:
>
> http://www8.pair.com/mnajtiv/tao.html
Vladimir:
What exactly are you trying to say. Have you got any "real"
specifications. Like how do you intend to interface your TAO object's to
NON-TAO operating systems that know nothing about TAO. TAO must run on a
hardware platform. Which one do you suggest. Somehow I get the idea that
it should probably run on any and every computer ever built and should
also be prepared to run on processors invented 5 years from now. Perhaps
TAO could even convince INTEL to build a TAO processor. Don't you agree?
If you can layout TAO'S internal structures ie: Interrupt stacks,
process trees, driver interfaces, etc I would be glad to start writing
code immediately.
However after examining your constraint "wish list" I find nothing that
the current OS's don't already do.
Have you taken a look at WEB-TV lately.
Regards.
------------------------------
From: [EMAIL PROTECTED] (Jonathan Abbey)
Crossposted-To: comp.security.unix
Subject: Re: PROPOSAL: A secure, simple NIS replacement
Date: 23 Aug 1999 12:43:03 -0500
In article <7pnt0t$kf9$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
| I woke up this morning with an idea for an NIS replacement almost fully
| formed in my head. It is so elegant that I had to share in the hopes
| that some folks out there would take on the challenge.
|
| ...
|
| This file would contain all of the configuration directives for the
| service (I'll call it "spass" from here on, just as a place-holder). It
| would look something like:
|
| # Do we accept client connections?
| server on
| # Do we get our info locally or remotely?
| # note that the local pluggable authentication module
| # for spass will still work, this just means that we maintain
| # our own passwd file.
| client off
| # Who do we serve and who do we trust?
| # Security: step 1. See encryption info later
| allowed_clients *.mydomain.com
| disallowed_clients bofo.mydomain.com
| # Security: step 2.
| # The first line (local_ignore) specifies which accounts the
| # local pam should dissavow knowledge of even though they
| # are in /etc/passwd (et al. including shadow info)
| local_ignore uid>=600
| # The next line (transmit_rule) specifies which accounts
| # should be sent to remote systems.
| transmit_rule uid>=500
| # In this particular scheme, all of our admins have uids from
| # 500 to 599, so they can log in on the server, but all other
| # users (600+) can only log in on the clients.
| ...
|
| Now, here's the fun part: the network protocol uses the same encryption
| as GPG (thus freely distributable, as far as I know). No verification
| (e.g. login) is done via the protocol, that's simply a matter of the
| configuration file on the server and client. Local IP spoofing might
| still result in some unauthorized access, but remote users would be
| completely unable to gain access (assuming that (a) your router does not
| allow spoofing to pass through and (b) your server's config file does
| not allow the world to gain access).
There have been several NIS-type ideas implemented... NIS, NIS+,
Kerberos/Hesiod, and the netinfo stuff that NeXT used. We still use
NIS for almost everything because of the ubiquity of it, but a lot of
people are moving to LDAP for this sort of thing.
It seems like what would be really valuable here would be encryption
support for LDAP, but I think they are already implementing LDAP on SSL
as a standard.. ?
| I have no time to write this right now (though it's vastly tempting),
| but if people who are willing to dedicate large gobs of time want to
| send me email, I'd be happy to introduce you all and perhaps even set up
| a majordomo list....
|
| -AJS
--
===============================================================================
Jonathan Abbey [EMAIL PROTECTED]
Applied Research Laboratories The University of Texas at Austin
Ganymede, a free NIS/DNS management system http://www.arlut.utexas.edu/gash2
------------------------------
From: Stephen Torri <[EMAIL PROTECTED]>
Subject: Re: Can't compile network drivers
Date: Mon, 23 Aug 1999 14:18:44 -0400
I did select config_experimental and the driver works. Thanks.
Stephen
Peter Samuelson wrote:
> Because use of these entries depends on some other option you didn't
> select earlier.
>
> In the case of the 8139, according to the source (see the file
> drivers/net/Config.in) it depends on CONFIG_EXPERIMENTAL, i.e. the very
> first config option "Prompt for development and/or incomplete
> code/drivers". Don't let that scare you off -- the driver seems to
> work OK for me.
>
> --
> Peter Samuelson
> <sampo.creighton.edu!psamuels>
------------------------------
From: Tranceport <[EMAIL PROTECTED]>
Subject: Telnet problem
Date: Mon, 23 Aug 1999 20:21:46 GMT
I'm more a developer than an admin, so I am probably screwing up
something:
when I try to telnet from one computer (Win or Linux, doesn't matter) to
a Linux box (RH6) after I enter login and password, I always get the
same answer, no matter what account I'm using: 'Login incorrect'.
Do I have to configure users so that they can access the machine
remotely?
Thanx
Trance
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Phil Howard)
Subject: Re: why does root need supplementary groups?
Date: Mon, 23 Aug 1999 18:53:50 GMT
On 18 Aug 1999 09:32:47 -0400 Doug DeJulio ([EMAIL PROTECTED]) wrote:
| In article <waru3.612$[EMAIL PROTECTED]>,
| Phil Howard <[EMAIL PROTECTED]> wrote:
| >Why does root need supplementary groups? Redhat and other
| >distributions, and even other Unix systems, put root in the
| >supplementary list for various groups in /etc/group. What's
| >the point in doing that? Doesn't root have almighty power?
|
| There are various contexts in which root does not have almighty power.
|
| Consider a program that starts running as root, and then uses a system
| call to change its UID away from root (or give up some of it's divine
| power some other way). It then does *not* have ultimate power, and
| the groups matter.
The standard supplementary groups are fairly powerful. Switching uid
and skipping groups would generally be an unsafe way to do things. So
programs should address what groups are to be in effect in the switch,
such as reloading the supplementary groups for the uid being switched
to. A program that fails to consider the groups is exposing a risk.
| Also, on NFS servers, root usually gets mapped to "nobody" on remote
| filesystems. Again, groups matter.
|
| Also, consider network file clustering systems like "AFS" (and
| probably the AFS-descended "CODA", though I'm not certain). Again,
| groups matter.
If I can assert to the server that I am root, that does open obvious
security problems, and so the mapping to "nobody" is appropriate.
The supplementary groups that are typically put in place by stock
installs of Redhat and Slackware (and even of other UNIX systems)
do grant a lot of power. If the NFS or AFS servers are trusting of
what the client machine asserts for group permissions, then isn't
that opening up quite a security hole itself?
| Also, consider software that uses groups in an advisory manner. "Hey,
| I notice you're not in group such-and-such, are you sure you want to
| do that?" In that case, ultimate power is irrelevant, as it's purely
| advisory. So, groups matter.
I can see some use for this. But in general, when I want to something
as root, I switch to root to do it, so I'm very intentional about it.
When I am root, when would there be a scenario in which I would want to
respond "no" to that? If it is a case where a non-root user should be
doing certain things, the program can just as easily if(!getuid()){}.
So it seems to me that if I remove all the supplementary groups from
root, I'm actually enhancing overall security, aside from problems that
would still be inherint in the trusting nature that appears might be
in existance in certain remote filesystem servers.
--
Phil Howard KA9WGN
[EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Tuomo Pyhala)
Crossposted-To: comp.security.unix
Subject: Re: PROPOSAL: A secure, simple NIS replacement
Date: Mon, 23 Aug 1999 20:54:14 GMT
English is not my native language, and i probably didn't completetely
understand your posting.
[[EMAIL PROTECTED] wrote...]
>On the server, the administrator would have only ONE extra file to
>manage (not counting the addition to the passwd entry in nsswitch.conf).
>This is a major part of the idea. It should integrate with a
>pam/nsswitch-capable UNIX system seamlessly and not require any extra
>databases, etc.
Actually, when designing such a system i would consider storing that
system's configuration just a minor detail, which should be designed after
the major decisions about objectives and implementation have been made.
>Now, here's the fun part: the network protocol uses the same encryption
>as GPG (thus freely distributable, as far as I know). No verification
>(e.g. login) is done via the protocol, that's simply a matter of the
>configuration file on the server and client. Local IP spoofing might
>still result in some unauthorized access, but remote users would be
>completely unable to gain access (assuming that (a) your router does not
>allow spoofing to pass through and (b) your server's config file does
>not allow the world to gain access).
If i would design such system, i would design it in client/server-model.
When considering the protocol i would set following objectives
1. At minimum following should be fulfilled in authentication process
* No password related data (passwords, hashes) should be available to
anybody listening communication channel, false clients or false servers.
* It shouldn't be possible to send spoofed message saying that "ok, that
was the correct password".
2. This probably implies authentication of server, clients and nice
protocol.
When considering other information binded to account (on unix say, gecos,
uid, gid and so on)
1. This information should be integrity protected, so that no
modifications can take place
Nice additional features
1. Encrypt also other information
2. Design protocol so that client passes password through encrypted
channel to server, which then tells either Success, Failed. Never
give hashes or such even clients to authorize users, nor users
themselves.
Implementation example:
Clients could be configured with strong keys (when compared to a
password derived key) to authenticate to server. These clients could then
securely establish communication channel (of course secure, strongly
encrypted and integrity protected) to server and authenticate their
users against server database. They could also retrieve the "other
information" from server. Server would implement access controls on which
users the client is authorized to authenticate and which information it is
allowed to retrieve.
But isn't this rather close to LDAPv3 protected with SSL/TLS?
>The protocol should be able to convey advanced user information such as
>account aging; non-DES password hashes; more-than-8-character usernames
>(perhaps allowing for systems that allow all sorts of weird characters
>in usernames); and perhaps even protocol applicability (e.g. this
>account only works from an apache plug-in or from the imap server).
The protocol should definitely be stretchable to allow different
hash-functions and long user names. Of course it would be nice to have
possibility to use weird cryptographic handshakes, 1-time passwords and
all kinds of little intelligent devices (these cards, what are they
called). It would be nice to have for example a ring which you could use
to open doors at office and authenticate to the computers.
It might be also desirable to have shared information about policy for
account, say that user joe is allowed to logon during 7:30-16:30 and he is
disallowed to use service foobar.
> 1. The additional pam (Pluggable Authentication Module)
> 2. The server (a caching server could be v 2.0)
Actually i would prefer say NSS+PAM modules so that no data would have to
be stored locally.
In later message you told about need to selectively import users to
machine. Actually this is interesting topic. When thinking further it
might even be desirable that accounts could be imported selectively from
several sources (say different organizational units keeping their own user
database).
Now it is interesting think about needed trust-relationships between
databases and clients. For example when considering unix-based
machines all the databases need to be in sync at some level. All the
accounts and groups should have unique uid's and gid's for example. Also
it would be nice to have features to disallow orgazional unit for example
assigning users to groups or setting their uid as zero. Actually i'm
How does kerberos and such systems implement this, they can however
authenticate users from other domains kdc's, if i remember this
correctly.
------------------------------
From: [EMAIL PROTECTED] (Benjamin Audy)
Crossposted-To: gnu.g++.help,comp.windows.x.kde,linux.dev.c-programming,comp.os.linux.x
Subject: Re: gdb trace of GUI apps core dumping on printf's
Date: Mon, 23 Aug 1999 21:20:28 GMT
It also happened to me recently when I ran a program from Kdevelop
(it's an IDE). Like you, it core dumped. But then, I already
successfully did that before in Kdevelop, so I'll have to look at it
to see exactly what is the problem. I wonder if it has something to do
with KDE or QT since you seem to use it, too.
I use Slackware 4.0 (kernel 2.2.6).
Benjamin Audy
[EMAIL PROTECTED]
------------------------------
From: Jonas Utterstrom <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Shared Libraries: what is the linux equivalent of "dllimport" and
"dllexport"
Date: Mon, 23 Aug 1999 20:47:12 GMT
In article <Cfhw3.616$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Josh Stern) wrote:
> Communicator 4.6 does link to a lot of shared libraries.
> But anyway, this clarification helps partly.
> Now where does the contrast between shared
> libraries based on C and C++ come into it?? Could you post the
> sizes of the libraries that you think represent the same code
> on Linux and on Windows and say what percentage C and C++ you
> estimate them to be? Also, do the Windows versions support
> exceptions, and if not, are exceptions turned off on the Linux
> versions?
Well hold your breath then, Mozilla uses 81 dlls or 88 so-files. Most of
them are small and looks more like plugins.
Here are some comparisons from the Mozilla M8 release:
The Linux version is compiled without rtti or exceptions. Especially
exceptions is an extremely bloat factor. The Linux binaries are also
stripped.
I know nothing of how the Windows version was compiled.
100% C++:
3637416 libraptorhtml.so
552236 librdf.so
424516 libxpcom.so
1204912 raptorhtml.dll
251824 rdf.dll
246336 xpcom.dll
And a 100% C library comparison:
41952 zlib.dll
53904 libz.so.1.1.3
The numbers speak for themselves.
For some more information, check this link out (probably broken but cut &
paste is easy):
http://bx6.deja.com/viewthread.xp?AN=490379424.1&search=thread&svcclass=dnser
ver&ST=PS&CONTEXT=935244203.987693076&HIT_CONTEXT=935244203.987693076&HIT_NUM
=3&[EMAIL PROTECTED]%3e%231/2&group=netscape.public.moz
illa.performance.size-matters&frpage=getdoc.xp&back=clarinet
/Jonas U
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Christopher R. Thompson" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Jesus: the ultimate OS
Date: Mon, 23 Aug 1999 12:42:42 -0700
Vladimir Z. Nuri wrote:
>
> an HTML version of this article can be found at:
>
> http://www8.pair.com/mnajtiv/tao.html
>
I'm going to name my OS "Jesus". It will coded primarily to destroy all
"EVIL" objects os's and computers. Only the objects that "LOVE" Jesus
will survive and communicate with "Jesus".
------------------------------
From: [EMAIL PROTECTED] (void)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 23 Aug 1999 19:48:18 GMT
On 23 Aug 1999 18:13:18 GMT, Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote:
>
>
> the ultimate OS
<cue flamewar>
--
Ben
[X] YES! I'm a brain-damaged lemur on crack, and I'd like to
order your software package for $459.95!
------------------------------
From: "Marshall" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking,comp.os.linux.hardware,linux.dev.net
Subject: Re: Netgear FA310TX
Date: Mon, 23 Aug 1999 17:54:35 -0400
<snip>
>I've seen at least two different versions of the FA310TX.
>
>The original version used the DEC 21140 chip. I've bought, and used,
>a bunch of these over the years, with very good results. The
>"tulip.c" driver in the kernel works well, although you may want to
>update to the latest version.
>
>Starting about a year ago, Netgear switched over to an FA310TX design
>which uses an OEM'ed Lite-On PNIC chip with a Netgear part number.
>Although the PNIC is supposed to be Tulip-compatible, and it _mostly_
>works with the Tulip driver, there are some definite problems.
I was not aware of this chip switch untill I saw your post. I am dismayed
that Netgear is using the same NIC model # in spite of the heart of the unit
being switched to another chipset.
>The biggest problem of which I'm aware, appears to be due to a bug in
>some versions of the PNIC chip. Under conditions of heavy load - and
>especially if collisions are occurring - the chip's receiver logic
>gets confused, and dumps a whole bunch of gibberish into memory. The
>Tulip driver does not deal gracefully with this situation, and tends
>to cease receiving anything at all from the card. It's necessary to
>restart the card (ifconfig down, ifconfig up, reestablish routes) to
>get it working again.
My short research seems to indicate that this is a O/S specific issue; would
you aggree with that ?.
Lastly; is it safe to assume that PNIC reports it self as such and not one
of the earlier chipsets ?.
<snip>
Thanks
Marshall
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Setting LD_LIBRARY_PATH from makefile
Date: 23 Aug 1999 03:01:06 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[David T. Blake <[EMAIL PROTECTED]>]
> Try
> export LD_LIBRARY_PATH=`pwd`:${LD_LIBRARY_PATH}
>
> OR
>
> LD_LIBRARY_PATH=`pwd`:${LD_LIBRARY_PATH} ; export $LD_LIBRARY_PATH
Bzzzt. This is inside a makefile. As someone already said, each line
of a makefile rule is executed in its own shells, so setting a variable
in one does not affect another.
If you just want LD_LIBRARY_PATH in one rule, use backslashes (\) to
end lines so that you effectively get one rule line:
target: $(TARGET_DEPENDS)
LD_LIBRARY_PATH=`pwd`:$(LD_LIBRARY_PATH) export LD_LIBRARY_PATH \
do_one_command;\
do_another_command;\
do_yet_another;
It's cumbersome for large rules. If on the other hand you want to set
LD_LIBRARY_PATH for the whole makefile, you can set LD_LIBRARY_PATH as
a make variable and then declare the phony target .EXPORT_ALL_VARIABLES
(I think this is a GNU make extension).
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Jonas Utterstrom <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Shared Libraries: what is the linux equivalent of "dllimport" and
"dllexport"
Date: Mon, 23 Aug 1999 08:08:42 GMT
In article <Xp_v3.437$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Josh Stern) wrote:
>
> What I wrote is not tantamount to bad-mouthing Mozilla developers.
> They may have had very important reasons (e.g. time pressure)
> for coding Netscape in a careless and sloppy way. My hypothesis
> of why Netscape is so big is a) it has a lot of features,
> and b) it was coded with the priority of minimizing time to market
> for a complex cross-platform app. Your "explanation" of why
> the Netscape executable is so big - because C++ shared libraries
> are much bigger than C shared libraries - was nonsensical bullshit.
>
I am a C++ programmer so I am not trying to fuel the C vs C++ flamewar.
I just compare with the size of Windows dlls. And the fact is that i.e.
Mozilla is twice as big in Linux.
>
> The run time performance depends on what gets loaded when.
> On Linux, resolution of references from a shared library
> is 'lazy' by default, meaning that they are resolved as
> needed during execution, so a particular module of code
> that is not used is likely to remain un-read on disk.
> Try 'man dlopen'. Or better yet, just adopt an empirical
> approach to the question and experiment as I suggested
> previously.
>
I do not really see your point here. One of the good things with shared
libraries is that they aren't loaded until they are actually used. But
when they are used, also the internal classes used by the public
interface will be loaded. And they will pollute the global symbol-table
for the dynamic linker.
>
> Yes, and do the easy experiment with your own applications to
> see what the effects of shared libraries and C++ really are. I
> think you will be pleasantly surprised.
>
Unless someone with more technical ELF merits steps forward I have to
get back to this issue later.
/Jonas U
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Marinos J. Yannikos)
Subject: Re: Volunteer: Device Drivers!!!
Date: Mon, 23 Aug 1999 20:54:12 GMT
On Sun, 22 Aug 1999 23:46:09 GMT,
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>Hello,
>
> I am a device driver writer (SVR4, Unixware, LynxOS, NT). I would
>like to work on a Linux device driver.
It would be nice if you could write an OSS device driver for the audio
subsystem of the NeoMagic MagicMedia 256AV. It isn't properly supported
yet, but it's used in many laptops. NeoMagic refuse to provide detailed
information about it though.
-mjy
--
***==> Marinos J. Yannikos <[EMAIL PROTECTED]>
***==> http://pobox.com/~mjy
------------------------------
** 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
******************************
