Subject: Re: kern/1043: unlink(2) should not let superuser remove directories
To: None <netbsd-bugs@NetBSD.ORG>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
List: netbsd-bugs
Date: 05/15/1995 14:32:09
> Well, if unlink() can't remove directories, than link() shouldn't be
> able to link them.

Agreed - I would also support yanking that code out of link() at the
same time.

>>> In any case, I have real strong philosophical problems with
>>> removing the ability of root to do *anything*... not just link and
>>> unlink directories.
>> There are lots of things even root can't do...does it bother you
>> that root can't write directly to directories?  Can't access kernel
>> VM directly?  Can't write a raw device whose block device is mounted
>> (rw) as a filesystem?  Can't bind() a socket to a port which already
>> has a socket listening to it?  Can't open the master side of a busy
>> pty pair?

> Well, it bothers me* that root can't write to directories, or to the
> raw device of a mounted filesystem.

> Some of the other actions you mentioned are actually nonsensical, as
> opposed to stupid or dangerous; these, I don't care about.

I picked those examples specifically because they're things root can't
curently do that I could easily define sensible semantics for.

Accessing kernel VM directly: why not?  Why shouldn't the kernel's VM
appear in a user process's address space?  Kernel and user normally use
disjoint regions of the address space anyway, if for no other reason
than to make kernel accesses to user-land VM easy.

Can't bind() a socket to a port which already has a socket listening:
why not?  It could either preempt the other socket, or it could cause
an incoming connection to be handed "randomly" to one or the other.

Can't open the master side of a busy pty pair: why not?  It would break
the traditional method of allocating ptys, but it would be easy enough
to do.  If you do it by requiring another bit, say, the O_NDELAY bit,
then it wouldn't even break that.

> Is there a holy-wars@netbsd.org we can move this all to?

I'm tempted to create one, running off my machine at home...but I know
I don't have the netlink bandwidth for it.

> [I]f we're all debating whether or not it's a bug, shouldn't we
> debate it elsewhere?

Um.  I'd say that by this point it's pretty clearly not a bug.  I no
longer have the original pr handy, but if it said sw-bug I'd say it was
misclassified; it's really a change request.  Whether it is a sensible
change is - obviously - debatable, but I don't think it's really a bug.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu