Subject: Linux-Development Digest #164
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Thu, 14 Oct 93 04:13:08 EDT

Linux-Development Digest #164, Volume #1         Thu, 14 Oct 93 04:13:08 EDT

Contents:
  Re: set*id (Jim Segrave)
  **** GCC 2.4.5 and Profiling ***** (Nguyen Ho)
  Re: Device-number size (was Re: Multi-port ...) (Matthias Urlichs)
  Re: possible bug in virtual console switching (Robert B. Martin)
  Re: books about [34]86 assembler programming? (Chris Hafey)
  Re: The %&#$@ speaks again -or- An apology (rich@mulvey.com)
  Has anyone written a Mac FS or Mac FS Access utilities for Linux or 386BSD? (Peter A Dinda)
  Re: The %&#$@ speaks again -or- An apology (rich@mulvey.com)
  pointer (Usenet News)
  Re: set*id (Theodore Ts'o)
  Re: The %&#$@ speaks again -or- An apology (Kevin Brown)
  Re: possible bug in virtual console switching (Dirk Hohndel)

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

From: jes@grendel.demon.co.uk (Jim Segrave)
Subject: Re: set*id
Date: Wed, 13 Oct 1993 21:09:11 +0000

In article <29hd3t$7gs@nz12.rz.uni-karlsruhe.de> ig25@fg30.rz.uni-karlsruhe.de (Thomas Koenig) writes:
>Both the BSD and the POSIX ways of dealing with setuid programs
>and set*uid() calls are flawed; Linux implements both of them ;-)
>
>It is good form for a suid root program to temporarily give up
>its privileges, so errors in the program cannot threaten system
>security.
>
>BSD - style setreuid has the flaw that effective userid's are inherited
>across exec() - calls; in other words, if the executable is somehow
>tricked into exec()ing an untrusted program, bad things can happen.
>The classic example of this was the fingerd bug which overran a
>buffer and got a shell for its pains...
>
>About POSIX - style setuid, to quote the kernel sources:
>
> * Note that SAVED_ID's is deficient in that a setuid root program
> * like sendmail, for example, cannot set its uid to be a normal
> * user and then switch back, because if you're root, setuid() sets
> * the saved uid too.  If you don't like this, blame the bright people
> * in the POSIX commmittee and/or USG.  Note that the BSD-style setreuid()
> * will allow a root program to temporarily drop privileges and be able to
> * regain them by swapping the real and effective uid.
>
>Soo... what is there to do?
Well, you could fork in the suid program, set your ids to a normal user in
the child, then exec from the child - there's no going back from the child
process or it's children to the previous privelege level. (though the
HP solution seems cleaner to me.


-- 
Jim Segrave        (Segrave Software Services jes@grendel.demon.co.uk)


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

From: nh@nguyen.ruhr.de (Nguyen Ho)
Subject: **** GCC 2.4.5 and Profiling *****
Date: 13 Oct 1993 00:36:08 -0000


Hello world,
recently I reinstalled Linux from scratch, also SLS 1.03.
With the early SLS release I was OK to do profiling with
gcc 2.3.3, but now the two files gcrt0.o and libgmon.a
required for profiling are missing.

I have got lib4.4.1 installed, but the lib4.4.2 shipped
with the actual SLS distribution still does not include
that missing files.

Anyone knows the location of that files ?
Are they included in other distributions, e.g Slackware ?

Thanks in advance.
-- 
+-----------------------------------------------------+
|  Nguyen_Ho@nguyen.ruhr.de     TEL : +49 201 503124  | 
|  DreiringPlatz 1              45276 Essen (Germany) |
+-----------------------------------------------------+

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

From: urlichs@smurf.sub.org (Matthias Urlichs)
Subject: Re: Device-number size (was Re: Multi-port ...)
Date: 13 Oct 1993 18:31:04 +0100

In comp.os.linux.development, article <28f3g0$23r@flode.nvg.unit.no>,
  agulbra@nvg.unit.no (Arnt Gulbrandsen) writes:
> 
> Wouldn't it be simpler to do as Stephen Tweedie (or was it Remy
> Card?) proposed, and go to 16-bit major and minor numbers?  Old

No. The TTY code is a mess because PTYs, console drivers, and dumb
serial devices share two major numbers. Those are very different devices -- 
the master side of a PTY doesn't have anything at all in common with your 
serial port, for instance -- so it makes sense to split them off.

Plus, as more drivers for character devices which might benefit from line 
disciplines (ISDN drivers, for instance) get available, the implementation 
will get more and more messy. The only way around the problem is a clean 
separation of functionality, and the only way to get that is to move to 
separate major numbers and a real terminal-device support library in the 
kernel instead of the inverted structure we have now (where the drivers
are essentially clients of the terminal driver).

> Since my .sig is so short I'll include it twice.

Yeah, right.

-- 
MANAGEMENT:
       The art of getting other people to do all the work.
-- 
Matthias Urlichs        \ XLink-POP N|rnberg   | EMail: urlichs@smurf.sub.org
Schleiermacherstra_e 12  \  Unix+Linux+Mac     | Phone: ...please use email.
90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing      42

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

Reply-To: bmartin@bmartin.win.net (Robert B. Martin)
From: bmartin@bmartin.win.net (Robert B. Martin)
Date: Wed, 13 Oct 1993 23:48:11 GMT
Subject: Re: possible bug in virtual console switching

 
>       This is exactly the problem.  If you switch from a graphics
>console (XFree86, dosemu, (s)vgalib) to a regular tty console (text),
>the keyboard functions as if you are holding down one of the shift
>keys (alt, ctl, shift).  To recover, just switch to two consecutive
>text consoles.  Of course this is not a true solution and I would be
>interested in the patch.  When I asked about this a while back, all the
>responses said that I needed a new loadkeys, but since I was
>using the US map, I never bothered.
>
I regularly switch between Xterms and VCs and have not experienced any problems.
I'm using 99pl13, bash and X 1.2 ( haven't installed 1.3 yet) with the 
openwindows enviroment. Also not using any of the distributions (SLS, Slack etc.)

later.....
--  
|  Bob Martin                                            |
|  bmartin@bmartin.win.net                               |


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

From: chafey@ecst.csuchico.edu (Chris Hafey)
Subject: Re: books about [34]86 assembler programming?
Date: 14 Oct 1993 00:44:16 GMT

In article <eyal.750515086@fir>,
Eyal Lebedinsky <eyal@fir.canberra.edu.au> wrote:
>In <1993Oct11.194111.9708@utex.rni.sub.org> michael@utex.rni.sub.org (Michael Utech) writes:
>
>>All i found was a book about MS-Assembler, not quite what i'm
>>looking for.
>
>There are many such books. One that I found informative is from PC
>Magazine, Programmer's Techincal Reference: The Processor and
>Coprocessor. The author is Robert L. Hummel, ISBN 1-56276-016-5.
>It is NOT the cheapest book...
>
>>Thank you!
>
>

  I have a book called "i486 Microprocessor programmer's reference manual".
It will not teach you assembly.  Its main purpose is to show knowledgabel 
assembly programmers how to use the 486 chip.  It discusses everything from
multi-tasking to memory management and all the goodies you need to write
an OS.  Here's some more info:

i486 Microprocessor programmer's reference manual
Intel Wrote It
Published by McGrawHill (also mentions Osborne)
$24.95

Chris


-- 
Chris Hafey                     |  True programming is rebooting the machine
chafey@ecst.csuchico.edu        |  after each crash until it works. 

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

Crossposted-To: news.groups
From: rich@mulvey.com
Subject: Re: The %&#$@ speaks again -or- An apology
Date: Thu, 14 Oct 1993 01:24:18 GMT

Aaron Barnhart (barnhart@Notwerk.mcs.com) wrote:
: rich@mulvey.com (Rich At Mulveycom) wrote:
: :[in response to someone else who writes:]
: :
: :: So until such a facility comes into being, cut the newbies some slack, eh?
: :
: :No, we won't.  Being a newbie isn't a crime - there are lots of things
: :that *I'm* a newbie at.  But I make a substantial effort to find the
: :answers to my questions without bothering people.  And when I *do*
: :encounter something that I'm lost about, then I post a *useful and
: :complete* description of my problem, what I've tried, and what I think
: :may be wrong.  The morons who post things like "My smail doesn't work.
: :What do I do?" have no place in any of these groups, or in society as
: :a whole, for that matter, until they learn how to not waste other
: :people's time.  Flaming the hell out of them is a useful memory-enhancing
: :technique that makes them think twice before asking stupid
: :questions again.
: :

: I would say at the rate you're going, Rich, ignorance will only
: be painful for those who don't learn to work the kill file.  

   Such is their right and their priviledge.  Personally, I already
have a substantial kill file.  :-)

: Since the Net continues to grow at approximately 30% a month,
: you can fairly expect to be "flaming the hell" out of a lot of
: people .. and it will still be a losing game, because for every
: one you thrill at sizzling to a crisp, there will be 200 others
: who will continue to torment you with their stupidity and
: ignorance ... until as I say they learn to hold the Control key
: while pressing K.

   Yup - it grows.  And I think that it's great - more people getting
connected means more funding, more acceptance of the concept of a
global info net, and easier access.  I enjoy being able to trade
ideas with college students in Hong Kong, dentists in Austria, and
pipe-fitters in Sacramento.  But with greater access comes the need
for greater discipline by the participants.  Take a look at a month's
worth of postings in the Linux groups sometime, and then scan how many
of the inappropriate postings are made by the *same* people, over and
over again.  I can recognize a few names off the top of my head of
specific persons who are continually asking questions that can be answered
by five minutes work with *any* Unix book.  Negative reinforcement may
not be Politically Correct, but it's usually a must faster and more
effective way of forcing someone to actually *think* the next time they
post.  

: I have a counterplan (as the future amateur-radio nuts used to
: say when they did high-school debate).  IGNORE THE IGNORAMUSES.
: Someone nice will give them the pointers to the FAQs and soon
: they'll be posting well-educated "guess-tions" to these groups
: and you won't answer them, either, I predict.  After all, what
: fun is that?

   Nice in theory, but as I said, look into the recent past.  People who
have their laziness rewarded, in general, don't bother to make more
of an effort the next time they have a question.  As for me "not answering
them", I suggest that *you* do a little research before making unfounded
accustations.  Since Sept. 1 of this year, I've made 14 public responses
to *reasonable* queries for help in the Linux groups, and a roughly
equivalent number of mail replies.  Look it up, bud.  Can you say the
same?

- Rich
-- 
Rich Mulvey                 Amateur Radio: N2VDS              Rochester, NY
rich@mulvey.com         "Ignorance should be painful."

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

Crossposted-To: comp.os.386bsd.development,comp.os.386bsd.misc
From: pdinda+@cs.cmu.edu (Peter A Dinda)
Subject: Has anyone written a Mac FS or Mac FS Access utilities for Linux or 386BSD?
Date: Thu, 14 Oct 1993 01:48:23 GMT


The subject sort of is the question.  By Mac FS for Linux/386BSD, I mean
a Vnode style foreign file system that can be mounted with the mount
command and is available via standard Unix file access calls.  

I am already aware of such DOS utilities as Macette and MacSEE.

Peter A. Dinda



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

Crossposted-To: news.groups
From: rich@mulvey.com
Subject: Re: The %&#$@ speaks again -or- An apology
Date: Thu, 14 Oct 1993 01:36:52 GMT

marauder (marauder@netsys.com) wrote:

: : No, we won't.  Being a newbie isn't a crime - there are lots of things
: : that *I'm* a newbie at.  But I make a substantial effort to find the
: : answers to my questions without bothering people.  And when I *do*
: : encounter something that I'm lost about, then I post a *useful and
: : complete* description of my problem, what I've tried, and what I think
: : may be wrong.  The morons who post things like "My smail doesn't work.
: : What do I do?" have no place in any of these groups, or in society as
: : a whole, for that matter, until they learn how to not waste other
: : people's time.  Flaming the hell out of them is a useful memory-enhancing
: : technique that makes them think twice before asking stupid
: : questions again.

: Richard, 

: That has got to be the lamest attempt at rationalizing a stupid activity as I
: think I've seen, and Ive been at this little telecom game a long time. If it
: makes you feel important, and superior to "flame the hell" out of a new user,
: fine, but please do us the favour of admitting to the tru motivation for your
: measly activity. In short Rich, grow up.

   Somehow I suspect that I've been at this "little telecom game" a lot 
longer than you.  :-)  What precisely *is* my true motivation for wanting
people to exercise a few brain cells and actually do some work?  I'm simply
dying to find out - I eagerly await your trenchent analysis.  As for 
growing up:  That is exactly what I am asking others to do.  If they don't
have to, should I?

: Marauder
: Legion of Doom! (ret)
: (todd)

How... special.

-- 
Rich Mulvey                 Amateur Radio: N2VDS              Rochester, NY
rich@mulvey.com         "Ignorance should be painful."

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

From: news@cs.yale.edu (Usenet News)
Subject: pointer
Date: Thu, 14 Oct 1993 00:26:00 GMT

        Uhh, could somebody mail a finger pointing to the Kernel
hacker's guide?
        Thanks
--
Angelos Karageorgiou | The opinions expressed above are nobody else's but
Yeian kai Eytyxeian  | mine,MINE,MIIINNE,MIIINNEEEE,aaaarrgghhhh..(*&#$$*((+_$%
Live long & Prosper  | NO CARRIER

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

From: tytso@athena.mit.edu (Theodore Ts'o)
Subject: Re: set*id
Date: 14 Oct 1993 01:03:40 -0400
Reply-To: tytso@athena.mit.edu (Theodore Ts'o)

   From: ig25@fg30.rz.uni-karlsruhe.de (Thomas Koenig)
   Date: 13 Oct 1993 17:15:41 GMT

   Both the BSD and the POSIX ways of dealing with setuid programs
   and set*uid() calls are flawed; Linux implements both of them ;-)

   BSD - style setreuid has the flaw that effective userid's are inherited
   across exec() - calls; in other words, if the executable is somehow
   tricked into exec()ing an untrusted program, bad things can happen.
   The classic example of this was the fingerd bug which overran a
   buffer and got a shell for its pains...

POSIX Saved setuid's have the same problem, if a the setuid program is
tricked into exec()'ing a untrusted program --- the effective userid is
inherited across exec()-calls as well.  (POSIX.1 B.3.1.2.2, lines
154-158) In fact, Appendix B of the POSIX standard states that the exec
functions always save the value of the effective user ID in the saved
setuid, whether or not the setuid bit is set.  (B.3.1.2, line
1883-1886).

And it's not really a "flaw", since it's mandated by POSIX --- there are
definitely Unix programs that depend on these semantics.  This "bug",
though, goes back to Unix V7, where /bin/mail was setuid, and if you
shelled out with the '!' command, you got a shell that was setuid root.
While this was a flaw, it wasn't fixed by mucking about in the kernel.
(In fact, if you compiled the same V7 mail on a POSIX system with saved
setuid, you'd get the same bug!!!)  

It was fixed by fixing the mail program so that it reset its effective
uid before execing the shell.  There's no replacement for careful
programming!

   It would appear that HP has found a good solution for this; maybe it
   would be a good idea for Linux, as well.  Here's what the HP-UX 8
   manpages have to say:

         int setresuid(uid_t ruid, uid_t euid, uid_t suid);

         setresuid sets the real, effective and/or saved user ID of the calling
         process.

I fail to see how this would help things at all --- the only
functionality which this grants you over what you have with the Linux
setreuid() is the ability to set the saved setuid manually.  How does
this help you any?  

(Especially since the Linux setreuid sets the saved setuid to the same
value as the effective uid --- so a program calling setreuid() can
really drop *all* of its privileges).

I put a lot of thought into how to make Linux support both AT&T and BSD
semantics fully --- and I believe the BSD semantics are perfectly
secure, as long as you the programmer uses them correctly.  

   And the exec(2) manpage tells us:

         The saved-user-ID and saved-group-ID of the process are always set to
         the effective-user-ID and effective-group-ID, respectively, of the
         process at the end of the exec, whether or not set-user(group)-ID is
         in effect.

Linux does this already; it is mandated by the POSIX standard.  But
again, I don't see how this helps you if the programmer of the setuid
program was idiotic enough not to reset the effective user ID before
exec'ing a program.  It's hard to make something foolproof, since fools
are so ingenious.  :-)

                                                - Ted

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

Crossposted-To: comp.os.linux.misc
From: kevin@frobozz.sccsi.com (Kevin Brown)
Subject: Re: The %&#$@ speaks again -or- An apology
Date: Thu, 14 Oct 1993 04:10:47 GMT

Followups to comp.os.linux.misc.

In article <1993Oct13.162636.8794@mulvey.com> rich@mulvey.com writes:
>Kevin Brown (kevin@frobozz.sccsi.com) wrote:
[...]
>: I can see why someone might not want to wade through the FAQ.  In all, the
>: FAQ is over 500k in size!!!  This is about the size of a paperback novel, I
>: think.  OF COURSE people aren't going to want to wade through the FAQ, and
>: for good reason: there's a lot of it to wade through.
>
>   So what if it's long?  Even the skimpy MS-DOS manuals that come with
>Our Favorite OS are longer.  

You should know better than this.  Most people don't learn DOS or any other
such thing from the manual.  They learn how to use the computer by asking
others who already know.  This is precisely why users like the Macintosh
so much: they don't *have* to pick up the manual, and they don't usually
have to ask someone else for the answers.  The Macintosh is "intuitive",
which is just another way of saying that it has enough similarities with
things that most people have experience with (e.g., the trashcan) that it
works the way people would *expect* it to work.

>Is it too much to ask that people make the
>*slightest* bit of effort?  What in the world is an index for, if not
>to help you look things up?

My own experience indicates that the "index" (which is no such thing,
really, but is rather a table of contents) is a poor way of locating the
information I'm looking for when I'm searching for the answer to a question.
I get much better results searching the actual text for certain keywords
and then examining the text surrounding the keywords.

>: Someone who knows enough about grep, regular expressions, etc., could
>: easily find the answers themselves, of course, but such a person would
>: probably be the type least in need of the FAQ to begin with.  You can
>: safely assume that people who are new to Linux are likely to be new to
>: Unix as well, and thus won't be familiar with the facilities that would
>: make their search for information in the FAQ relatively painless.
>
>Not necessarily.  A person who has the ability to use an editor to post
>a stupid question is likely to know that you can search for text, as
>well.

I don't think so, given what I've seen of most users.  But since most users
I've seen don't even know what Unix is, I can't really comment on this.

But I will say this: even among the students in my own computer science
department, only a handful of them know how to use the search facilities
of the editor.  Most of them search by "hand".

>: So until such a facility comes into being, cut the newbies some slack, eh?
>
>No, we won't.  Being a newbie isn't a crime - there are lots of things
>that *I'm* a newbie at.  But I make a substantial effort to find the
>answers to my questions without bothering people.  

Independent of the ethical question involved here, I would say you're
unusual in this respect.  I'm the same as you are, to the extent that I
will search the source code to find what I'm looking for before asking
a question.  This is why I've asked so few questions.

Most people are not "self-starters" to the extent that computer experts
typically are, at least when it comes to technology.  When faced with a
computer or *any* other piece of technology they are unfamiliar with, most
people will stop dead in their tracks unless they have someone to ask about
the problem.  Many of them won't even *think* of reading the manual.  If
you don't believe me, take a look at how few people know how to program
their VCR, and of those who do know, take a look at how few of them found
out by reading the manual rather than having someone *show* them.

>And when I *do*
>encounter something that I'm lost about, then I post a *useful and
>complete* description of my problem, what I've tried, and what I think
>may be wrong.  

Yup.  But you, I, and most of us who tend to do this are essentially experts
at working with technology.  We know the ups and downs and know that the key
to understanding technology is learning about the principles behind the
technology.  We know what kinds of questions to ask and the level of detail
necessary because we've dealt with *answering* questions like that before.
How many can claim this?  Not many, given what I've seen.

I think that most computer types are first-principle oriented.  It's a
necessary qualification for doing a good job of working with technology.
But most people aren't first-principles oriented, they're *procedure*-
oriented.  If you need evidence for this, take a look at the mix of
books in the computer section of your local bookstore.  You will find
that it is heavily dominated by "how-to" books, and you will find that
these books are very heavily procedure-oriented in their approach.  There
is a reason for that.

>The morons who post things like "My smail doesn't work.
>What do I do?" have no place in any of these groups, or in society as
>a whole, for that matter, until they learn how to not waste other
>people's time.  

Welcome to the real world.  :-) :-)

Seriously, most people won't bother to learn more than they have to in
order to get the job done.  If they did, then *everyone* would be
technologically literate.

>Flaming the hell out of them is a useful memory-enhancing
>technique that makes them think twice before asking stupid
>questions again.

Wrong.  Flaming the hell out of them is a useful memory-enhancing technique
that makes them think twice before asking *any* question of the people they
asked before.  You're ignoring a very basic principle of education: a question
is *never* a stupid question from the point of view of the person asking the
question.  Very few people like to look stupid in front of other people.  If
they're asking a question, it's because they DON'T KNOW HOW to get the answer
for themselves, or at the very least are very uncomfortable and uncertain
about it.


-- 
Kevin Brown                                     kevin@frobozz.sccsi.com
This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end >
            This is your .signature virus on drugs: <>
                        Any questions?

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

From: hohndel@informatik.uni-wuerzburg.de (Dirk Hohndel)
Subject: Re: possible bug in virtual console switching
Date: 13 Oct 1993 14:29:22 GMT

Kevin Brown (kevin@frobozz.sccsi.com) wrote:

: >>There was a bug in the keyboard driver that made it confuse the state of
: >>modifier keys when switching between raw and nonraw consoles. I thought
: >>that was fixed in pl13, at least a patch for that was sent to Linus. (I
: >>can't currently verify that with dosemu or X, I don't have a working
: >>version of them installed.)
: >
: >
: >Well, I'm running pl12, so that would make sense.  Can anyone confirm
: >(or deny) that the bug was fixed in pl13?

: The bug was not fixed in pl13, which is what I'm currently running.

: The bug did not exist in pl10, which is what I was running before.  It's
: not clear to me why this bug crept in...

: References to the patch for this would be appreciated...

Linus told me it is fixed in the latest ALPHA on nic

        Dirk

--
 _     _           _            _   _     |  Lehrstuhl Informatik I
| | | |_) |/  |_| | | |_| |\ | | | |_ |   |  Universitaet Wuerzburg
|_/ | | \ |\  | | |_| | | | \| |_/ |_ |_  |  Am Hubland, D-97074 Wuerzburg

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


** 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: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU

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

    Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU

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