Two bugs: sticky bit directory and ld -e

[Hannu-Matti J{rvinen]

I can't recall if these problems have been discussed before, but here they
are:

1) Sticky bit in directories

Sticky bit in directories prevents removing the files in the directory
without write privilege to the file and the directory. (Without sticky
only directory write permission is needed). But what happens if you use mv
to rename files without write protection in a directory with the sticky
bit and write permissions? mv happily creates a new link for the file to
be renamed, but can't remove the old link. So mv works essentially as ln.
BUT: mv does this for directories, too. ln prevents the hard linking of
two directories for the superuser only, by mv and sticky bit anybody can
do it. But nobody can remove the created link, not even the superuser.

Further, fsck can remove such links, but any time it finds one during
boot, the boot will fail because of an "unexpected inconsistency".  So I
classify this as a bug in mv-command, which do not check beforehand all
the permissions needed to do the job.

2) ld -e (SunOs 4.0.1)

ld -Bstatic /usr/lib/crt0.o test.o -lc will produce static linking and
result shared executables. After several experiments ld -e start -Bstatic
etc. was found to make static linking and result to not shared
executables. Nothing in the man page of ld tells me, why option -e has
this kind of effect.  -e implies -Bsymbolic, but ld -Bsymbolic -Bstatic
produces shared executable, so there IS something -e does but man doesn't
know about.

Hannu-Matti Jarvinen, Tampere University of Technology, Finland
hmj at tut.fi, hmj at tut.uucp, hmj at tut.funet (tut.ARPA is not the same computer).

[[ I do not fully understand your problem #1.  I was not able to recreate
it on a 4.0.1 system.  Have you confirmed that this is a problem?  If so,
can you please provide a series of commands that will recreate it?  "mv"
used to work by linking and unlinking, but it no longer does.  It uses the
"rename" system call.  So I don't see how the problem as you have
described it could exist.  Also, the "unlink" system call will let the
super user unlink directories, even if there are still files in that
directory.  So I believe that, even if one could create an additional link
to a directory, the super user can still remove it.  I tried recreating
the situation you described in (1), but I could not get it to behave the
way you said it does.  But I've been wrong before....   --wnl ]]