Hello,
> exactly. The question is: Is it a Solaris bug or is it something that is
> supposed a user is able to do (it doesn't make sense for me)? I posted
> this problem to comp.unix.solaris and also contacted the UFS Maintainer
> of Solaris (it is not the first UFS bug I original found). If I don't
> receive feedback, I am going to open a call with Sun. Whatever is going
> on (hopefully it isn't PEBKAC - but I don't think so) and this time it
> isn't broken hardware either (like the last time I reported a serious
> git bug) because it happens on two machines.
below I quote the answer of the UFS maintainer:
Thomas,
some notes on the unlink(directory) part:
In the case of calling unlink(2) on a directory as a privilidged user, things
like ".." (and the link count in the parent) would not be cleaned up.
The man page for unlink(1M) and unlink(2) is very clear about using rmdir(1/2) to
remove a directory. It's also very clear that this does exactly what
it's supposed to do: Remove a link to a file/directory. Cleaning up
the ".." entry (which would clean up the link to the parent) could
be considered "extra".
First the standards issues:
The link(BA_OS) and unlink(BA_OS) descriptions in SVID3 both specify that
a process with appropriate privileges is allowed to operate on a directory.
We have claimed to conform to SVID3 since Solaris 2.0 and have not announced
that we ever plan to EOL SVID3 conformance.
UFS does support link(2)/unlink(2) with appropriate privilidges of
directories while ZFS does not.
The change that would provide ``Cleaning up the ".." entry ...'' would
violate both SVID3 and POSIX and SUS requirements. (The unlink(path)
system call is supposed to remove the directory entry named by path; not
the directory entry named by path and an arbitrary number of other
directory entries.)
Second some history:
Back before there were mkdir() and rmdir() system calls, applications
wanting to create a directory invoked the setuid root mkdir utility
which performed a series of mknod() and link() operations to create the
directory and create dot and dot-dot entries in the new directory.
Similarly, applications wanting to remove a directory invoked the
setuid root rmdir uility which performed a series of unlink()
operations to destroy the directory if it was empty.
Not quite so far back in ancient history, there is also the point
that before symlinks were available it was common practice to make
hard links to directories. Privileged applications can still do this
today (as mandated by SVID) using the link() and unlink() system calls
and the link and unlink commands.
UFS and ZFS are actually both correct, the standards wording permits either way kind of:
<snip>
If path1 names a directory, link() shall fail unless the process has
appropriate privileges and the implementation supports using link() on directories.
The path argument shall not name a directory unless the process has
appropriate privileges and the implementation supports using unlink() on directories.
<snip end>
This seems to implicitely allow an escape route; we can declare that no process
has sufficient privileges to link(2)/unlink(2) directories or like ZFS did,
have the underlaying implementation not supporting it at all.
The proper way is for the application to use the rmdir(2) system call,
it's there since ages!
my bottom line: GIT should not call unlink on a directory.
Thomas
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
