Security question: "Text file busy" overwriting executables but not shared libraries?
Alexander Viro
On Tue, 2 Oct 2001, Rob Landley wrote:
> Anybody want to venture an opinion why overwriting executable files that are
> currently in use gives you a "text file busy" error, but overwriting shared
> libraries that are in use apparently works just fine (modulo a core dump if
> you aren't subtle about your run-time patching)?
>
> Permissions are still enforced, but it seems to me somebody who cracks root
> on a system could potentially modify the behavior of important system daemons
> without changing their process ID numbers.
>
> Did I miss something somewhere?
Somebody who cracks root can attach gdb to a daemon, modify the contents of
its text segment and detach. No need to change any files...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jesse Pollard
> On Tue, 2 Oct 2001, Rob Landley wrote:
>
> > Anybody want to venture an opinion why overwriting executable files that are
> > currently in use gives you a "text file busy" error, but overwriting shared
> > libraries that are in use apparently works just fine (modulo a core dump if
> > you aren't subtle about your run-time patching)?
> >
> > Permissions are still enforced, but it seems to me somebody who cracks root
> > on a system could potentially modify the behavior of important system daemons
> > without changing their process ID numbers.
> >
> > Did I miss something somewhere?
>
> Somebody who cracks root can attach gdb to a daemon, modify the contents of
> its text segment and detach. No need to change any files...
True, but the original problem still appears to be a bug.
Even the owner of the file should not be able to write to a busy executable,
whether it is a shared library, or an executable image. Remove it, yes.
Create a new one (in a different inode) - yes.
But not modify a busy executable.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pol...@navo.hpc.mil
Any opinions expressed are solely my own.
Eric W. Biederman
> Alexander Viro <vi...@math.psu.edu>:
> > On Tue, 2 Oct 2001, Rob Landley wrote:
> >
> > > Anybody want to venture an opinion why overwriting executable files that are
>
> > > currently in use gives you a "text file busy" error, but overwriting shared
>
> > > libraries that are in use apparently works just fine (modulo a core dump if
>
> > > you aren't subtle about your run-time patching)?
> > >
> > > Permissions are still enforced, but it seems to me somebody who cracks root
>
> > > on a system could potentially modify the behavior of important system
> daemons
>
> > > without changing their process ID numbers.
> > >
> > > Did I miss something somewhere?
> >
> > Somebody who cracks root can attach gdb to a daemon, modify the contents of
> > its text segment and detach. No need to change any files...
>
> True, but the original problem still appears to be a bug.
>
> Even the owner of the file should not be able to write to a busy executable,
> whether it is a shared library, or an executable image. Remove it, yes.
> Create a new one (in a different inode) - yes.
>
> But not modify a busy executable.
Have ld-linux.so set the MAP_DENYWRITE bit when it is mapping
the library.
Eric
Eric W. Biederman
> On Wednesday 03 October 2001 14:06, Eric W. Biederman wrote:
>
> > > But not modify a busy executable.
> >
> > Have ld-linux.so set the MAP_DENYWRITE bit when it is mapping
> > the library.
>
> And of course since the FSF wrote it, it's not quite that simple...
>
> >/* The right way to map in the shared library files is MAP_COPY, which
> > makes a virtual copy of the data at the time of the mmap call; this
> > guarantees the mapped pages will be consistent even if the file is
> > overwritten. Some losing VM systems like Linux's lack MAP_COPY. All we
> > get is MAP_PRIVATE, which copies each page when it is modified; this
> > means if the file is overwritten, we may at some point get some pages
> > from the new version after starting with pages from the old version. */
>
> I.E. it seems like they go out of their way to ALLOW writing to the libaries.
> (I assume they KNOW the difference between MAP_DENYWRITE, MAP_COPY, and
> MAP_PRIVATE...?)
>
> This look right to anybody else? Or am I about to wander into weird
> side-effect land? (Is there a reason they DON'T want a read-only mapping?
> Are they writing data into those pages, perhaps doing the linking fixup
> stuff? What?)
You definentily need to do some writing to do the fixups.
The deny write solves the problem of somone potentially writing to the
file at a later date.
Probably what is needed is:
#ifndef MAP_COPY
# ifdef MAP_DENYWRITE
# define MAP_COPY (MAP_PRIVATE | MAP_DENYWRITE)
# else
# define MAP_COPY MAP_PRIVATE
# endif
#endif
>
> --- elf/dl-load.bak Wed Oct 3 18:53:37 2001
> +++ elf/dl-load.c Wed Oct 3 18:55:57 2001
> @@ -48,7 +48,7 @@
> means if the file is overwritten, we may at some point get some pages
> from the new version after starting with pages from the old version. */
> #ifndef MAP_COPY
> -# define MAP_COPY MAP_PRIVATE
> +# define MAP_COPY MAP_DENYWRITE
> #endif
>
> /* Some systems link their relocatable objects for another base address
>
> I should just try this and see what it does. On a machine I don't mind
> reinstalling from scratch. Which means I need to dig up a spare keyboard for
> my junk machine... (And figure out how to get glibc's ./configure script to
> realise that linuxthreads is, in fact, there in the source directory. It's
> right there. Use it. Don't yell at me it's not there. I didn't make this
> SRPM, I changed one line... Sigh...)
>
> In the morning...
For testing you can do ./ld-linux.so program to run a program under to
see if it actually works.
Alexander Viro
On 3 Oct 2001, Eric W. Biederman quoted:
> > >/* The right way to map in the shared library files is MAP_COPY, which
> > > makes a virtual copy of the data at the time of the mmap call; this
> > > guarantees the mapped pages will be consistent even if the file is
> > > overwritten. Some losing VM systems like Linux's lack MAP_COPY. All we
> > > get is MAP_PRIVATE, which copies each page when it is modified; this
> > > means if the file is overwritten, we may at some point get some pages
> > > from the new version after starting with pages from the old version. */
IMO it needs a slight correction.
+ /* Unfortunately, that is not an option, since losing bloatware like GNU's
+ relies heavily on equally bloated shared libraries and use of MAP_COPY
+ would eat memory with no mercy. OTOH, implementing it might be a good
+ idea, since results would force people to switch to something less obese */
Linus Torvalds
Rob Landley <lan...@trommello.org> wrote:
>
>I.E. it seems like they go out of their way to ALLOW writing to the libaries.
> (I assume they KNOW the difference between MAP_DENYWRITE, MAP_COPY, and
>MAP_PRIVATE...?)
Note that the kernel will refuse to honour MAP_DENYWRITE from user
space, so I'm afraid that changing ld.so won't do a thing.
The reason the kernel refuses to honour it, is that MAP_DENYWRITE is an
excellent DoS-vehicle - you just mmap("/etc/passwd") with MAP_DENYWRITE,
and even root cannot write to it.. Vary nasty.
Which is why the kernel only allows it when the binary loader itself
sets the flag, because security-conscious application writers are
already aware of the "oh, a running binary may not be writable" issues.
So sorry..
Linus
Alexander Viro
On Thu, 4 Oct 2001, Linus Torvalds wrote:
> The reason the kernel refuses to honour it, is that MAP_DENYWRITE is an
> excellent DoS-vehicle - you just mmap("/etc/passwd") with MAP_DENYWRITE,
> and even root cannot write to it.. Vary nasty.
<nit>
I _really_ doubt that something does write() on /etc/passwd. Create a
file and rename it over the thing - sure, but that's it.
</nit>
Linus Torvalds
On Thu, 4 Oct 2001, Alexander Viro wrote:
> <nit>
> I _really_ doubt that something does write() on /etc/passwd. Create a
> file and rename it over the thing - sure, but that's it.
> </nit>
Well, yeah, bad choice. Can you believe /var/run/utmp or similar?
And yes, we could add checks for the thing being executable before we
accept MAP_DENYWRITE instead of just ignoring the flag from user space.
Nobody has cared enough to make the effort.
Until now?
Linus
Richard Gooch
> <nit>
> I _really_ doubt that something does write() on /etc/passwd. Create a
> file and rename it over the thing - sure, but that's it.
> </nit>
# vi /etc/passwd
Regards,
Richard....
Permanent: rgo...@atnf.csiro.au
Current: rgo...@ras.ucalgary.ca
Eric W. Biederman
> On 3 Oct 2001, Eric W. Biederman quoted:
>
> > > >/* The right way to map in the shared library files is MAP_COPY, which
> > > > makes a virtual copy of the data at the time of the mmap call; this
> > > > guarantees the mapped pages will be consistent even if the file is
> > > > overwritten. Some losing VM systems like Linux's lack MAP_COPY. All we
>
> > > > get is MAP_PRIVATE, which copies each page when it is modified; this
> > > > means if the file is overwritten, we may at some point get some pages
> > > > from the new version after starting with pages from the old version. */
>
>
> IMO it needs a slight correction.
>
> + /* Unfortunately, that is not an option, since losing bloatware like GNU's
> + relies heavily on equally bloated shared libraries and use of MAP_COPY
> + would eat memory with no mercy. OTOH, implementing it might be a good
> + idea, since results would force people to switch to something less obese */
Hmm. Perhaps. But if we went there we would need to add something like.
/* But finding a less obese platform to run these less obese libraries is a
challenge. Unix clones like UZI have been shown to run a complete system
including user space binaries in just 64KB of RAM, on systems
originally designed to run CPM. But today you can't find a general
purpose kernel whose binary much less it footprint fits in 256KB.
It seems bloatware is everywhere.
*/
I have days when I'm frustrated by the size of both glibc and the
linux kernel. stripped both the linux kernel and glibc are comparable
in size. Though I think the 400KB of compressed glibc-2.1.2 is
actually smaller than the kernel for the most part. I have to strip
off practically everthing to get a useable bzImage under 400KB.
So any good ideas on how to get the size of linux down?
Eric
George Greer
>Which is why the kernel only allows it when the binary loader itself
>sets the flag, because security-conscious application writers are
>already aware of the "oh, a running binary may not be writable" issues.
One of the methods I tried to use to stop a fork()-bomb was to zero the
executable in question to force it to crash. No such luck, reboot it was.
Not that I can think of any other useful application of said behavior.
--
George Greer, gre...@m-l.org
http://www.m-l.org/~greerga/
john slee
On Thu, Oct 04, 2001 at 06:21:27PM +1000, CaT wrote:
> On Thu, Oct 04, 2001 at 12:15:01AM -0600, Eric W. Biederman wrote:
> > I have days when I'm frustrated by the size of both glibc and the
> > linux kernel. stripped both the linux kernel and glibc are comparable
> > in size. Though I think the 400KB of compressed glibc-2.1.2 is
> > actually smaller than the kernel for the most part. I have to strip
> > off practically everthing to get a useable bzImage under 400KB.
> >
> > So any good ideas on how to get the size of linux down?
>
> Mind if I ask why you need a bzimage under 400kb? Just curious as I've
> never had the need. (And I can see needing it less then 1.4meg - are you
> trying to get a kernel AND a ramdisk on the one floppy?)
plenty of reasons. i'm building a compactflash-based linux router which
will only have 16mb of flash for the entire system... saving 100kb means
you can fit a few extra userspace tools in there...
-rwxr-xr-x 1 indigoid indigoid 54444 Oct 4 18:30 boa*
j.
--
R N G G "Well, there it goes again... And we just sit
I G G G here without opposable thumbs." -- gary larson
Ville Herva
>
> <snip size of glibc>
Where size is an issue, diet libc might be an alternative:
(287kB statically linked zsh is not too shabby, I reckon.)
That and things like busybox:
I have no suggestion wrt the kernel, though.
-- v --
CaT
> I have days when I'm frustrated by the size of both glibc and the
> linux kernel. stripped both the linux kernel and glibc are comparable
> in size. Though I think the 400KB of compressed glibc-2.1.2 is
> actually smaller than the kernel for the most part. I have to strip
> off practically everthing to get a useable bzImage under 400KB.
>
> So any good ideas on how to get the size of linux down?
Mind if I ask why you need a bzimage under 400kb? Just curious as I've
never had the need. (And I can see needing it less then 1.4meg - are you
trying to get a kernel AND a ramdisk on the one floppy?)
--
CaT "As you can expect it's really affecting my sex life. I can't help
it. Each time my wife initiates sex, these ejaculating hippos keep
floating through my mind."
- Mohd. Binatang bin Goncang, Singapore Zoological Gardens
Andreas Schwab
|> So any good ideas on how to get the size of linux down?
How about linux-0.01?
SCNR.
Andreas.
--
Andreas Schwab "And now for something
Andreas...@suse.de completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
CaT
> > Mind if I ask why you need a bzimage under 400kb? Just curious as I've
> > never had the need. (And I can see needing it less then 1.4meg - are you
> > trying to get a kernel AND a ramdisk on the one floppy?)
>
> will only have 16mb of flash for the entire system... saving 100kb means
> you can fit a few extra userspace tools in there...
>
> -rwxr-xr-x 1 indigoid indigoid 54444 Oct 4 18:30 boa*
Well, duh. :)
Thanks. :)
--
CaT "As you can expect it's really affecting my sex life. I can't help
it. Each time my wife initiates sex, these ejaculating hippos keep
floating through my mind."
- Mohd. Binatang bin Goncang, Singapore Zoological Gardens
Erik Andersen
> On Thu, Oct 04, 2001 at 12:15:01AM -0600, you [Eric W. Biederman] claimed:
> >
> > <snip size of glibc>
>
> Where size is an issue, diet libc might be an alternative:
>
> http://www.fefe.de/dietlibc/
>
> (287kB statically linked zsh is not too shabby, I reckon.)
uClibc is also a nice alternative. Works just great and uses glibc
header files. I only fully support shared libs on x86 and arm
at the moment.
http://cvs.uclinux.org/uClibc.html
(I need to update the webpage sometime)
> That and things like busybox:
>
> http://busybox.lineo.com/
Why thanks. I've sure worked hard to make it be nice and small...
-Erik
--
Erik B. Andersen email: ande...@debian.org, formerly of Lineo
--This message was written using 73% post-consumer electrons--
John Levon
> The reason the kernel refuses to honour it, is that MAP_DENYWRITE is an
> excellent DoS-vehicle - you just mmap("/etc/passwd") with MAP_DENYWRITE,
> and even root cannot write to it.. Vary nasty.
why is MAP_EXECUTABLE dealt with in the same way then ?
john
--
" It is quite humbling to realize that the storage occupied by the longest line
from a typical Usenet posting is sufficient to provide a state space so vast
that all the computation power in the world can not conquer it."
- Dave Wallace
Eric W. Biederman
> ebie...@xmission.com (Eric W. Biederman) writes:
>
> |> So any good ideas on how to get the size of linux down?
>
> How about linux-0.01?
There might be some fodder there, but I doubt it. I have
played with linux-lite-v1.00 (which is something like linux-1.09).
And couldn't get any really compelling results. Plus for it to be
useful I would still need to backport all of the driver API's from
2.4.x.
Just for a note, UZI has been ported to x86 as UZIX so a 32KB kernel
(without a network stack is achievable on x86). If I can get a core
kernel size with no drivers down to 64KB or less I would be happy.
So far I haven't been able to come up with anything satisfying.
Eric
Eric W. Biederman
> On Thu, Oct 04, 2001 at 12:15:01AM -0600, Eric W. Biederman wrote:
> > I have days when I'm frustrated by the size of both glibc and the
> > linux kernel. stripped both the linux kernel and glibc are comparable
> > in size. Though I think the 400KB of compressed glibc-2.1.2 is
> > actually smaller than the kernel for the most part. I have to strip
> > off practically everthing to get a useable bzImage under 400KB.
> >
> > So any good ideas on how to get the size of linux down?
>
> Mind if I ask why you need a bzimage under 400kb? Just curious as I've
> never had the need. (And I can see needing it less then 1.4meg - are you
> trying to get a kernel AND a ramdisk on the one floppy?)
floppies have lots of room.
I'd like to get a kernel, ramdisk, and some hw initialization code all
on a 256KB ROM. I have my ramdisk down to about 14KB compressed. I
have my hw initialization code down to 32KB uncompressed (and I might
be able to reduce that further). So I want something like a 192KB
(compressed) linux kernel.
If I had that some of the hard problems of with linuxBIOS would just
drop away.
Eric W. Biederman
> On Thu, 4 Oct 2001, Alexander Viro wrote:
> > <nit>
> > I _really_ doubt that something does write() on /etc/passwd. Create a
> > file and rename it over the thing - sure, but that's it.
> > </nit>
>
> Well, yeah, bad choice. Can you believe /var/run/utmp or similar?
>
> And yes, we could add checks for the thing being executable before we
> accept MAP_DENYWRITE instead of just ignoring the flag from user space.
> Nobody has cared enough to make the effort.
>
> Until now?
Hmm. Before I volunteer I need to think this thing out. I orginally
missed the clearing of MAP_DENYWRITE in the arch specific code.
First what user space really wants is the MAP_COPY. Which is
MAP_PRIVATE with the guarantee that they don't see anyone else's changes.
Just skimming /lib most libraries are only rw by root so the case we
are protecting ourselves against is fumble fingered administrators.
The two fumbles in particular are fumbling the permissions, and
accidentaly writing to a shared library.
given that MAP_DENYWRITE does remove unlink permission for most uses it
can be worked around.
We already allow user space applications to make arbitrary files
MAP_DENYWRITE simply by executing them, and the only restriction is
that MAP_DENYWRITE only persists while user space has the file open.
So I guess allowing it in mmap is not actually a problem, as we can
already do that.
At the same time there are cases where it is unacceptable to stop
people from writing to a file just because you have read access to it,
and you open the file. Even having write access to a file isn't
enough. So you really need to have execute and read permissions on a
file for this to be reasonable.
The one downside of requiring libraries to be executable is that
tricks like preventing. /lib/ld-linux.so.2 /mnt/noexec/bin/true is
a little harder.
A remaining question was for newer kernels should MAP_DENYWRITE fail
if you don't have execute permissions, or should it just be a strong
hint.
Having MAP_DENYWRITE fail on filesystems that are mounted noexec and
having a dynamic loader that tests looks like it would be easier to
enforce a noexec policy for untrusted mounts.
So the code will need to look something like.
if (flags & MAP_DENYWRITE) {
struct inode *inode = file->f_dentry->inode;
if (IS_NOEXEC(inode) || !ISREG(inode->i_mode) ||
(permission(inode, MAY_EXEC) != 0)) {
return -EACCESS;
Richard Gooch
>
> On 4 Oct 2001, Eric W. Biederman wrote:
> >
> > First what user space really wants is the MAP_COPY. Which is
> > MAP_PRIVATE with the guarantee that they don't see anyone else's changes.
>
> example of how absolutely and stunningly _stupid_ Hurd is.
Indeed. If you're updated a shared library, why not *create a new
file* and then rename it?!? That lets running programmes work fine,
and new programmes will get the new library. Also, the following
construct makes a lot of sense:
ld -shared -o libfred.so *.o || mv libfred.so /usr/local/lib
Why? Because if ld(1) fails for some reason, and ends up writing a
short file, *you don't want to install the bloody thing*!!! Any new
user would be stuffed (no way around that, even with MAP_COPY).
I don't want to install/upgrade to a half-working library. What's the
point in that?
Regards,
Richard....
Permanent: rgo...@atnf.csiro.au
Current: rgo...@ras.ucalgary.ca
Alexander Viro
On Thu, 4 Oct 2001, Linus Torvalds wrote:
> In short, now you need filesystem versioning at a per-page level etc.
*ding* *ding* *ding* we have a near winner. Remember, folks, Hurd had been
started by people who not only don't understand UNIX, but detest it.
ITS/TWENEX refugees. And semantics in question comes from there -
they had "open and make sure that anyone who tries to modify will get
a new version, leaving one we'd opened unchanged".
> Trust me. The people who came up with MAP_COPY were stupid. Really. It's
> an idiotic concept, and it's not worth implementing.
Well, actually that's a concept that made sense on system we got mmap from[1]
They just want infection to be complete.
[1] cue Tom Lehrer singing "I got it from Agnes, she got it from Jim"
Linus Torvalds
On 4 Oct 2001, Eric W. Biederman wrote:
>
> First what user space really wants is the MAP_COPY. Which is
> MAP_PRIVATE with the guarantee that they don't see anyone else's changes.
Which is a completely idiotic idea, and which is only just another example
of how absolutely and stunningly _stupid_ Hurd is.
The thing with MAP_COPY is that how do you efficiently _detect_ somebody
elses changes on a page that you haven't even read in yet?
So you have a few choices, all bad:
- immediately reading in everything, basically turning the mmap() into a
read. Obviously a bad idea.
- mark the inode as a "copy" inode, and whenever somebody writes to it,
you not only make sure that you do copy-on-write on the page cache page
(which, btw, is pretty much impossible - how did you intend to find all
the other _non_COPY_ users that _want_ coherency).
You also have to make sure that if somebody changes the page, you have
to read in the old contents first (not normally needed for most
changes that write over at least a full block), but you also have to
save the old page somewhere so that the mapping can use it if it faults
it in later. And how the hell do you do THAT? Especially as you can
have multiple generations of inodes with different sets of "MAP_COPY"
on different contents..
In short, now you need filesystem versioning at a per-page level etc.
Trust me. The people who came up with MAP_COPY were stupid. Really. It's
an idiotic concept, and it's not worth implementing.
And this all for what is a administration bug in the first place.
In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd
people.
Linus
Andreas Schwab
|> Linus Torvalds writes:
|> >
|> > On 4 Oct 2001, Eric W. Biederman wrote:
|> > >
|> > > First what user space really wants is the MAP_COPY. Which is
|> > > MAP_PRIVATE with the guarantee that they don't see anyone else's changes.
|> >
|> > Which is a completely idiotic idea, and which is only just another
|> > example of how absolutely and stunningly _stupid_ Hurd is.
|>
|> Indeed. If you're updated a shared library, why not *create a new
|> file* and then rename it?!? That lets running programmes work fine,
|> and new programmes will get the new library. Also, the following
|> construct makes a lot of sense:
|> ld -shared -o libfred.so *.o || mv libfred.so /usr/local/lib
^^
That || should be &&, otherwise you are doing exactly the opposite of what
you want.
Andreas.
--
Andreas Schwab "And now for something
Andreas...@suse.de completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
Eric W. Biederman
Wow what a wild spin off of my stream of consciousness.
Linus Torvalds <torv...@transmeta.com> writes:
> On 4 Oct 2001, Eric W. Biederman wrote:
> >
> > First what user space really wants is the MAP_COPY. Which is
> > MAP_PRIVATE with the guarantee that they don't see anyone else's changes.
>
> Which is a completely idiotic idea, and which is only just another example
> of how absolutely and stunningly _stupid_ Hurd is.
Well in this case it is Mach not Hurd, and I wouldn't be suprised if
you could find MAP_COPY in selected BSDs. The semantics wanted are
very reasonable. You only want to see your changes to a given file.
In practice there is no reason that anyone needs to actually change
the file so MAP_PRIVATE | MAP_DENYWRITE is much more sensible (at
least implementation wise).
> The thing with MAP_COPY is that how do you efficiently _detect_ somebody
> elses changes on a page that you haven't even read in yet?
Definentily.
> Trust me. The people who came up with MAP_COPY were stupid. Really. It's
> an idiotic concept, and it's not worth implementing.
I quite agree that MAP_COPY is not worth implementing. And I never
said otherwise. I only mentioned so I could think what the
alternatives where and what it's benefits really were.
> And this all for what is a administration bug in the first place.
Probably. I can't think of any other cases where this could trigger.
However I think is is sensible to export MAP_DENYWRITE to user space.
It cheaply closes the administration bug, it is partially exported
already, and can even allow dynamic loaders to follow the kernel
noexec policy.
The latter looks like an actual advantage over MAP_COPY. Though
somehow MAP_EXECUTABLE sounds like a better name...
Eric
Richard Gooch
> |> >
> |> > On 4 Oct 2001, Eric W. Biederman wrote:
> |> > >
> |> > > First what user space really wants is the MAP_COPY. Which is
> |> > > MAP_PRIVATE with the guarantee that they don't see anyone else's changes.
> |> >
> |> > Which is a completely idiotic idea, and which is only just another
> |> > example of how absolutely and stunningly _stupid_ Hurd is.
> |>
> |> file* and then rename it?!? That lets running programmes work fine,
> |> and new programmes will get the new library. Also, the following
> |> construct makes a lot of sense:
> |> ld -shared -o libfred.so *.o || mv libfred.so /usr/local/lib
>
> of what you want.
Yeah. Of course. Brain fart. Fingers faster than brain syndrome...
Regards,
Richard....
Permanent: rgo...@atnf.csiro.au
Current: rgo...@ras.ucalgary.ca