On Sun, May 05, 2002 at 04:27:47PM -0400, Roland McGrath wrote:
> Oh, that EISDIR must be from opening with write permission in
> netfs_attempt_lookup. I made it check for EROFS or EISDIR as it does for
> EACCES. If there are other possible errors for an O_RDWR open that aren't
> possible for a O_RDONLY open, we should check for those as well. Or we
> could make it just ignore any error except for some common cases like
> ENOENT in the first two tries and only report the error on the third. But
> I'd rather not repeat the calls for most errors if we can avoid it.
It is amazing from where these things crop up. I have now found the problem
with the chroot() case. In fact, it had nothing to do with settrans, and it
had nothing to do with chroot either.
The problem is symbolic links. We get ENOTDIR from file_name_lookup_under
when trying to open a symbolic link to a file with the O_EXEC bit set, and
we don't catch this in netfs_attempt_fakeroot. I have not verified it, but
had I to venture a guess I would say this comes from the EOPNOTSUPP in
diskfs's dir_lookup:
/* Check permissions on existing nodes, but not new ones. */
{
if (((type == S_IFSOCK || type == S_IFBLK || type == S_IFCHR ||
type == S_IFIFO)
&& (flags & (O_READ|O_WRITE|O_EXEC)))
|| (type == S_IFLNK && (flags & (O_WRITE|O_EXEC))))
error = EOPNOTSUPP;
I have worked around this in netfs_attempt_lookup by ignoring ENOTDIR if we
try to open with O_EXEC, but this doesn't look quite right. Is there a
better fix? Why are we looking up with O_NOLINK anyway?
Also, from looking at the above code, looking up any socket, fifo or other
special device will fail in netfs_attempt_lookup, with the same error. If
my work around was correct, then we need to always ignore ENOTDIR. And,
another thing, shouldn't we try to lookup the node in netfs_attempt_lookup
with O_NORW as a very last resort?
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
