[3451] in Athena Bugs
chgrp: several bugs (all platforms)
daemon@ATHENA.MIT.EDU (probe@ATHENA.MIT.EDU)
Thu Oct 19 15:43:13 1989
From: probe@ATHENA.MIT.EDU
Date: Thu, 19 Oct 89 15:42:32 -0400
To: bugs@ATHENA.MIT.EDU
Reply-To: Richard Basch <probe@ATHENA.MIT.EDU>
1) chgrp -R can abort at different times if the ownership of files in
subdirectories is not that of the user. Basically, if a file returns
an error because the user is not the owner of the file, it will set
an error flag and continue processing the directory. If it finds
that it has to traverse a directory, it sets the error flag equal
to the status of the chgrp -R of that child directory, however if
there are any errors in a subdirectory, processing of the current
directory is also aborted immediately. Thus, you can get different
results simply by the way the directory is ordered.
2) chgrp -R actually checks your grouplist and user id in the program
before attempting to chgrp the file. This is not correct since for
remote filesystems, there is no reason that the uid's must be the
same to permit the call. The client should use the return status
of the chown() call, rather than doing this sanity checking... For
instance, I am an administrator on the testers.athena.mit.edu AFS
cell and am therefore permitted to do any chgrp I like, but the
program is not permitting me because of its sanity checking. Who
is to say that my id on the client workstation corresponds to that
of the server?
3) When fixing the first two bugs, I decided to check the return status
of the chown() call against EPERM, as described in the manual page.
Apparently, the kernel is returning EACCES instead, which is supposed
to indicate that I could not follow the path to the given file/dir
specified.
In essence, I have two problems with the client /bin/chgrp program and
one problem with the chown() call within the kernel.
(And I thought #2 was going to be a 30 second fix, which is how all this
started...)
-Richard :(
