🚀 go-pugleaf

In article <1059@cci632.UUCP> rrw@cci632.UUCP (Rick Wessman) writes:
>In our version of Unix*, PERPOS**, it is legal to remove ".", and there
>is a raging controversy about whether it should be.

Since directories in the Unix file system are required to have "."
and ".." entries, it does not make sense to permit their removal.

The best solution would seem to be to use system calls to create
and remove directories, instead of super-user privileged processes
that invoke link(2) and unlink(2).  This also lets you avoid race
conditions that the latter approach is heir to.

Current BSD and System V releases have mkdir(2) and rmdir(2) calls.

> Since directories in the Unix file system are required to have "."
> and ".." entries, it does not make sense to permit their removal.

I tend to agree, but consider this from the S5R3 "mvdir.sh" script:

	/etc/unlink $t/..

which is required if you are to move directories from one containing
directory to another.

> The best solution would seem to be to use system calls to create
> and remove directories, instead of super-user privileged processes
> that invoke link(2) and unlink(2).  This also lets you avoid race
> conditions that the latter approach is heir to.

The same is true for moving directories.  A "rename(2)" system call
permits you to move directories in unprivileged programs without
having to invoke a privileged directory-moving program.  It also
obviates the need to allow users to remove or create ".." links.

> Current BSD and System V releases have mkdir(2) and rmdir(2) calls.

Current BSD releases have "rename(2)", and since "rename" is in POSIX
future System V releases will probably have it as well.

In article <1059@cci632.UUCP> rrw@cci632.UUCP (Rick Wessman) writes:
>Is it possible under vanilla System V to unlink "."? We have
>the source, and from what I can tell, it is legal.

Yes, it is legal.  It has to be, since (at least in versions prior to V.3)
there is no system call to create or delete a directory in one piece.  Thus,
in order to create a directory you have to do a mknod followed by explicit
creation of "." and ".."; to delete it, you must do the opposite, again one
step at a time.

>If it is legal, should it be OK to be able to remove it when the
>directory is not empty?

In my opinion, no, although I can see the "but then it's not UN*X"
responses coming now!  Of course, determining whether or not a directory
is empty is (or at least has the potential to be) a very expensive
operation.  Besides, the "correct" solution is to provide the
mkdir and rmdir system calls and then prohibit any modification of "."
and ".." from outside the kernel.

In article <1059@cci632.UUCP>, rrw@cci632.UUCP (Rick Wessman) writes:
> Is it possible under vanilla System V to unlink "."? We have
> the source, and from what I can tell, it is legal.
> 

rm/rmdir will not let you remove dot.  It is not a good idea to that
and they avoid this pitfall.  But if you are root, and you bypass their
protection by using the link/unlink system calls you can unlink the "."
entries and link directories as well.  This can make an unholy mess
out of your filesystem.

-Ron

In article <5715@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> In article <1059@cci632.UUCP> rrw@cci632.UUCP (Rick Wessman) writes:
> >In our version of Unix*, PERPOS**, it is legal to remove ".", and there
> >is a raging controversy about whether it should be.
> 
> Since directories in the Unix file system are required to have "."
> and ".." entries, it does not make sense to permit their removal.
> 
> The best solution would seem to be to use system calls to create
> and remove directories, instead of super-user privileged processes
> that invoke link(2) and unlink(2).  This also lets you avoid race
> conditions that the latter approach is heir to.
> 
> Current BSD and System V releases have mkdir(2) and rmdir(2) calls.

In the absense of rmdir(2) and rename(2) calls, you must be able to unlink
directory entries "." and "..".

If your rmdir(1) program doesn't bother to unlink ".", then the directory will
not go away and fsck(1) will decide that it is orphaned and place it in
/lost+found.

The next problem has to do with renaming directories.  If you do not permit
".." to be removed, then cd .. from the renamed directory won't work.

Doug is right about the races, but if you start moving all of the utilities
into the kernel, Sys5 will wind up looking a little fat.  There are plenty
of good reasons to let people unlink "." and "..".  Fix the races instead.

- john.		(jfh@killer.UUCP)

No disclaimer.  Whatcha gonna do, sue me?

As quoted from <1059@cci632.UUCP> by rrw@cci632.UUCP (Rick Wessman):
+---------------
| Is it possible under vanilla System V to unlink "."? We have
| the source, and from what I can tell, it is legal.
+---------------

Dunno about non-root, but --

Once I was trying to relink our kernel and (being that there was not enough
documentation, Plexus Tech Support finally set me right about :mkuts68; you
did the "make" directly under Plexus Sys3) passed make the wrong arguments.
It unlinked .. and I had to manually relink it -- fsck didn't even complain
about it.

+---------------
| If it is legal, should it be OK to be able to remove it when the
| directory is not empty?
+---------------

A directory is an ordinary file, except that nobody can write to it and
only root can link/unlink it (I hope!).  I think that link() and unlink()
should fail on directories and that mkdir() and rmdir() should be system
calls.  Now if only we had source (Plexus gives you conf.c and name.c, plus
lots of object libraries and low.s, but no kernel source).

++Brando
-- 
 ____   ______________
/    \ / __   __   __ \   Brandon S. Allbery		|      /^\      USS
 ___  | /__> /  \ /  \    aXcess Company		|     A A A  CHALLENGER
/   \ | |    `--, `--,    6615 Center St. #A1-105	|     H V H
|     | \__/ \__/ \__/    Mentor, OH 44060-4101		|     H . H    SEVEN
\____/ \______________/   +1 216 974 9210		|    /  |  \    WHO
________________________________________________________|   /___|___\  DARED
As long as there is the spirit to dare new frontiers, the dream will never die.
cbatt!cwruecmp!ncoast!allbery ncoast!allbery%case.CSNET@relay.CS.NET BALLBERY
	    (UUCP)                      (CSNET/Internet)             (MCIMail)

>Doug is right about the races, but if you start moving all of the utilities
>into the kernel, Sys5 will wind up looking a little fat.  There are plenty
>of good reasons to let people unlink "." and "..".  Fix the races instead.

Wrongo.  First of all, you're not moving "the utilities" into the
kernel.  There's more to the "mkdir" and "rmdir" than the system
calls of the same name.

Second of all, there are some annoying restrictions caused by the
lack of these calls; a program that is set-UID to somebody other than
"root" can't create or destroy directories using its set-UID
protection, since the "mkdir" and "rmdir" commands must be set-UID
"root" and, as such, will throw away the old set-UID privileges when
they are run (remember, vanilla V7, S3, and S5 won't let you set the
real UID to match the effective UID).

Third of all, directories are an abstraction whose implementation is
hidden from applications when you do lookups of names in directories
or creation of new names.  As such, the implementation of directories
should be hidden from programs creating or destroying them as well.

You might barely be able to argue against this in systems that
support only one type of file system.  However, both systems using
the Sun "vnode" mechanism or the S5R3 File System Switch can support
many *different* types of file systems, not all of which would permit
you to create directories using the code from the old-style "mkdir"
command or to remove them using the code from the old-style "rmdir"
command.

The cleanest way of doing this is to make "mkdir" and "rmdir" into
system calls and provide per-file-system-type entries for creating
and removing directories.

Even if it were possible to fix the races without providing "mkdir"
and "rmdir" system calls, that wouldn't be a reason to "fix the
races" and leave those calls out of the kernel.  Yeah, it makes the
system fatter, but if you really worry about every single thing that
is put into system you should be running V6.  (I'd rather not, thank
you.)

And if you don't want S5 to acquire "mkdir" and "rmdir", you're too
late.  They're already there.

In article <709@brl-sem.ARPA> ron@brl-sem.ARPA (Ron Natalie <ron>) writes:
>...
>rm/rmdir will not let you remove dot.  It is not a good idea to that
>and they avoid this pitfall.  But if you are root, and you bypass their
>protection by using the link/unlink system calls you can unlink the "."
>entries and link directories as well.  This can make an unholy mess
>out of your filesystem.

Once upon a time I wrote a routine to do sort of a "symbolic link",
putting one directory in another such that directory C seemed to be a
subdirectory of both A nd B. Obviously the value of .. was not
consistant, but I avoided rewriting a large BSD application. Someone
later used this to link a directory in itself (I assume by stupidity
rather than malace). Then they tried to run a dump... You're right, it
DOES make a mess.
-- 
bill davidsen			sixhub \
      ihnp4!seismo!rochester!steinmetz ->  crdos1!davidsen
				chinet /
ARPA: davidsen%crdos1.uucp@ge-crd.ARPA (or davidsen@ge-crd.ARPA)

As quoted from <736@killer.UUCP> by jfh@killer.UUCP (John Haugh):
+---------------
| > In article <1059@cci632.UUCP> rrw@cci632.UUCP (Rick Wessman) writes:
| > >In our version of Unix*, PERPOS**, it is legal to remove ".", and there
| > >is a raging controversy about whether it should be.
|
| Doug is right about the races, but if you start moving all of the utilities
| into the kernel, Sys5 will wind up looking a little fat.  There are plenty
| of good reasons to let people unlink "." and "..".  Fix the races instead.
+---------------

No, there aren't.  When it was decided to go with a directed graph rather
than an arbitrary linked mishmash, "." and ".." became sources of trouble.
Unless you want to go back to the old format (and Ghod help fsck!), it's
best to make the kernel force "." and ".." to be correct via mkdir()/rmdir()/
rename().  Otherwise you're asking for trouble.

System V ld unlinks the destination if it encounters an error.  I once tried
to relink the sysV kernel (as root, due to file permissions) and did it wrong;
ld tried to write ./.., failed for the obvious reasons, and unlinked the
destination.  Worse, fsck didn't let out a peep; I had to use /etc/link to
fix it.

This is a VERY good reason to make "." and ".." only linkable internal to the
kernel and force mkdir()/rmdir()/rename() outside it.

++Brando
-- 
 ____   ______________
/    \ / __   __   __ \   Brandon S. Allbery		|  QUOTE OF THE DAY:
 ___  | /__> /  \ /  \    aXcess Company		|
/   \ | |    `--, `--,    6615 Center St. #A1-105	|	  `
|     | \__/ \__/ \__/    Mentor, OH 44060-4101		|
\____/ \______________/   +1 216 974 9210		|
cbatt!cwruecmp!ncoast!allbery ncoast!allbery%case.CSNET@relay.CS.NET BALLBERY
	    (UUCP)                      (CSNET/Internet)             (MCIMail)

Yes - I insisted that '.' and '..' should be able to be linked and unlinked.
Yes - Guy Harris jumped all over me for being so stupid.
Yes - I jumped all over Guy Harris for jumping all over me.

But I still haven't figure out how any one proposes you unlink a *single*
directory entry given the restrictions imposed by rmdir(2).

I still think there needs to be some way to do this.  How about rmnod(2)? ...

- John.

Disclaimer:
	No disclaimer.  Whatcha gonna do, sue me?

In article <753@killer.UUCP> jfh@killer.UUCP (John Haugh) writes:
>... but if the
>mkdir(2) and rmdir(2) require you to be root in the first place ...

But they don't, and that's a very important reason for having them.

>...  The applications they
>develope are written to use the minimal subset of features from all Unix
>versions.

But that's pretty minimal indeed (it doesn't include any special
terminal handling, for example).  One of the goals of POSIX (IEEE
1003 standard) is to provide a more functional base than that.

>Of course, the system calls are always resident and taking up some of that
>not-so-plentiful-on-all-machines memory.

OK, please give numbers indicating the performance cost of putting
"mkdir" and "rmdir" into the system.

>I haven't looked at the documentation for S5R3 yet, so I really don't know
>what I am talking about here.  It seems that you can always spawn a mkdir(1)
>or rmdir(1) sub-process to create/delete your directories, but if the
>mkdir(2) and rmdir(2) require you to be root in the first place

They don't require you to be "root"; please read the documentation
first.

>(can you imagine
>	void crash ()
>	{
>		for (;;) {
>			mkdir ("a");
>			chdir  ("a");
>		}
>	}
>as you favorite subroutine? :-)

So what?  I can think of lots of things that can hang a system up.
This is hardly any sort of argument against making "mkdir" a system
call.

>Nice argument.  I would not like to work on a system with more than one
>or two different types of file systems.  I have a hard enough time fixing
>broken file systems as it is without having to learn another new one.

Other people either want to or need to work on a system with multiple
file system types.  The fact that *you* wouldn't like to work on such
a system doesn't mean such systems shouldn't exist.

>As for the Sun systems you work on, many of the features you are adding
>are not used by developers because of the differences between V7, BSDxxx
>and USG Systems III, IV and V.  If you would like some proof of this,
>talk with some at Uniplex Integration Systems.  The applications they
>develope are written to use the minimal subset of features from all Unix
>versions.

Some developers *do* use those features.  There's a tradeoff between
using various not-available-in-systems-released-prior-to-1980
features (which makes your code more portable, but can reduce its
performance, reliability, or functionality) and using them.  In some
cases it may be better to say "sorry, we won't support this program
under V7".

>It is possible to fix the races in the kernel without adding the calls.

But is it possible to fix the *other* problems caused by the absence
of those calls except by adding them?

>And as for making the system fatter, when I was installing USG 4.0 on
>a PDP-11/45 about 5 or 6 years ago, the system almost didn't fit because
>it had gotten so fat.  When USG 5.0 came out in 81 or 82, it didn't fit
>because there was so much junk in it.  As more stuff is added, it gets
>harder and harder to cram Unix into the limited memory that many of these
>machines have.

So?  It'd be hard to run even V6 on an 8K PDP-8.  Memory is getting
cheaper; sometimes you can use up more memory and get real benefits
from it.

>This is getting a bit ridiculous.

A bold statement, made with no apparent justification.  What is the
dividing line between a ridiculous and a sensible kernel size?  What
is a criterion that can be used for deciding which features "belong"
and which don't?  Do you want a hard limit on the kernel size, which
should apply from the time it's imposed until the heat-death of the
universe?

>There used to be one way to do everything in Unix.  And that was picked
>to be the most flexible one possible.  I guess times have changed.

Yes, times have changed.  The new solution - "mkdir" and "rmdir"
system calls - now offers more *useful* flexibility than the old
solution, given the existence of multiple file system types.

>I don't know if you paid any attention to the discussion about trashed file
>names, but it seems to me that a system call that won't let you unlink a
>directory with file entries in it is going to prevent the usual fix to this
>problem - unlink the directory and run fsck(1).

The *correct* fix to this problem is to have "fsck" treat directory
entries containing names with embedded NUL characters as being
scrambled directory entries, blast those entries, and then if
necessary put entries in "lost+found" for the files referred to those
entries.  The fact that the "usual" fix requires you to unlink
directories is irrelevant here.

In article <753@killer.UUCP>, jfh@killer.UUCP (John Haugh) writes:
> I don't
> know if you paid any attention to the discussion about trashed file names,
> but it seems to me that a system call that won't let you unlink a directory
> with file entries in it is going to prevent the usual fix to this problem -
> unlink the directory and run fsck(1).
> 

Beats me what kind of trashy fsck you have if you think this will
achieve anything, with any reasonable fsck at all, what you've just
described is a pretty slow way to do ...

	set -- `ls -id $dir`
	mv $dir /.../lost+found/#$1

That is, upon finding an unlinked directory, fsck will simply relink
it into lost+found, all the files in it remain as they were.

kre

As quoted from <753@killer.UUCP> by jfh@killer.UUCP (John Haugh):
+---------------
| In article <16186@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes:
| > Second of all, there are some annoying restrictions caused by the
| > lack of these calls; a program that is set-UID to somebody other than
| > "root" can't create or destroy directories using its set-UID
| > protection, since the "mkdir" and "rmdir" commands must be set-UID
| > "root" and, as such, will throw away the old set-UID privileges when
| > they are run (remember, vanilla V7, S3, and S5 won't let you set the
| > real UID to match the effective UID).
| > 
| I haven't looked at the documentation for S5R3 yet, so I really don't know
| what I am talking about here.  It seems that you can always spawn a mkdir(1)
| or rmdir(1) sub-process to create/delete your directories, but if the
| mkdir(2) and rmdir(2) require you to be root in the first place (can you
+---------------

No, you can't.  Please note that my UNaXcess Conferencing provides its own
mkdir command (mkconf) because the UC directories are not readable or writeable
by anyone but the owner of UC, and the "ua" executable runs setuid.  Therefore
a mkdir will FAIL ALWAYS because it runs as uid=who-ran-ua, euid=root but UC
needs uid=owner-of-ua.

This is (to say the least) a bad solution to a bad problem.  Unfortunately,
there is no GOOD solution short of moving mkdir() into the kernel.

Why don't I just allow anyone to scribble in the UC directories?  Ever heard
of security?

+---------------
| > the Sun "vnode" mechanism or the S5R3 File System Switch can support
| > many *different* types of file systems, not all of which would permit
| > you to create directories using the code from the old-style "mkdir"
| > command or to remove them using the code from the old-style "rmdir"
| > command.
| > 
| As for the Sun systems you work on, many of the features you are adding
| are not used by developers because of the differences between V7, BSDxxx
| and USG Systems III, IV and V.  If you would like some proof of this,
| talk with some at Uniplex Integration Systems.  The applications they
| develope are written to use the minimal subset of features from all Unix
| versions.
+---------------

Counterexample:  Informix Software, Inc.  Informix-SQL uses directories,
and is capable of being networked.  (In fact, they also use my solution:
look up $INFORMIXDIR/lib/makedir.)

+---------------
| It is possible to fix the races in the kernel without adding the calls.
| And as for making the system fatter, when I was installing USG 4.0 on
| a PDP-11/45 about 5 or 6 years ago, the system almost didn't fit because
| it had gotten so fat.  When USG 5.0 came out in 81 or 82, it didn't fit
| because there was so much junk in it.  As more stuff is added, it gets
| harder and harder to cram Unix into the limited memory that many of these
| machines have.  Sure, M68000's don't have a 64K text space.  But, many
| modern CPU's have such squirrely addressing that a massively huge Unix
| kernel really puts a dent in either the performance, or the amount of
| available memory.
+---------------

And lack of them really puts a dent in database operations -- the SINGLE
biggest use of computers in business.  System V provides THREE kinds of
mutual-exclusion primitives:  record locking (Vr3), semaphores, and messages
(see a good book on message-passing systems for info on how to use messages
for mut/ex).  V7 supplies NONE, and databases can therefore get into trouble.

BTW, what do you define as a modern CPU?  PDP/11?  iAPXx86?  I laugh.  The
first is dated, the second is a glorified 8080 no matter what its address
space it.  (80386 is the exception.  Intel finally decided to build a CPU
that wasn't an 8080 with cheap bank switching.)

MODERN CPUs are 68020, 32032, MicroVAX, etc. -- all of which handle the
address space needed for real work in the real world (read databases).

+---------------
| Yes, I run Version 7 at home.  Running size(1) on /unix gives me numbers
| something like 57000+20000+32000 or about 110K.  But have you looked at
| YOUR kernel lately?  Here are two 5.2 systems I use:
| 
| 3B2/400:	168704+25576+801536=972K
| Plexus P/60:	247060+18528+162740=418K
+---------------

So?  (NB:  I use a P/60 with SysV at work.)  If you need the features, they
have to go in.  And I dare you to set up a multiuser database under V7 that
will NEVER suffer from lock problems due to race conditions.

+---------------
| There used to be one way to do everything in Unix.  And that was picked
| to be the most flexible one possible.  I guess times have changed.  I don't
| know if you paid any attention to the discussion about trashed file names,
| but it seems to me that a system call that won't let you unlink a directory
| with file entries in it is going to prevent the usual fix to this problem -
| unlink the directory and run fsck(1).
+---------------

The correct fix is to fsdb the directory.  The REAL correct fix is to make
fsck put files with bad names in lost+found.

Flexible -- fine.  `.' and `..' are in fact flexible.  TOO flexible.  UNIX
went to directed graphs (and made `.' and `..' obsolete) when it was discovered
that arbitrarily linked directories could NOT be checked for consistency.  If
you disagree, remove setuid from mkdir and rmdir and tell the kernel that it's
okay for nonroot to link and unlink directories; then you have `.' and `..' in
their most flexible form, and you can kiss fsck goodbye.  Soon afterward you
can kiss your file system goodbye.

Small is beautiful, but too small is useless and therefore ugly.

++Brando
-- 
.--, .-----------,	Brandon S. Allbery	cbatt!cwruecmp!ncoast!allbery
    Y .-, .-, .-,	aXcess Company		ncoast!allbery@case.CSNET
.--,| +-' `-, `-,	6615 Center St. #A1-105		(@relay.cs.net)
|   A `-' `-' `-'	Mentor, OH 44060-4101	MCIMail: BALLBERY
`--' `-----------'	+01 216 974 9210	(UANet: "UANet FlagShip":Sysop)