linux-kernel - Re: [PATCH 00/17] [RFC] AFS: Implement OpenAFS pioctls(version)s

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <28259.1245261823@redhat.com>
Date:	Wed, 17 Jun 2009 19:03:43 +0100
From:	David Howells <dhowells@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	dhowells@...hat.com, Andreas Dilger <adilger@....com>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	akpm@...ux-foundation.org, linux-afs@...ts.infradead.org,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH 00/17] [RFC] AFS: Implement OpenAFS pioctls(version)s

Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> What _I_ mean is that THIS IS IMPOSSIBLE TO DO FROM USER SPACE!
> 
> Try it. Not doable. User space simply doesn't know enough, and has 
> fundamental races with mount/umount.

Ummm...  I'm not sure I completely agree.  If you've managed to open, say,
"/afs", where's the race with mount/umount?  You've got a file descriptor you
can use as a handle.  Yes, you have to check that it's actually an inode of
your fs, but that's not exactly difficult, and that's not going to change just
because someone unmounts it or mounts over it whilst you've got it open.

However, that makes userspace have to assume that the pioctl handler is on an
AFS inode, perhaps any AFS inode.  This is not compatible with OpenAFS as it
stands, and also means you can't use the AFS pioctls before mounting anything,
and you can't mount it elsewhere and expect it to work.

> End result: you do need a new system call. 
> 
> I just don't think "pioctl()" is a good one.

Out of interest, why not?  Is it just because it's another multipexor?  Or is
it because it's been abused to have pathless commands?

> You'd be better off with some modification of open and then use ioctl.

So you'd say use:

	fd = open("/the/target/file", O_SUPPRESS | (nofollow?O_NOFOLLOW:0));
	ioctl(fd, cmd, &args);
	close(fd);

where O_SUPPRESS (or whatever) suppressed override of the ops tables by the
chardev and blockdev handlers, and allows symlinks to be opened, rather than:

	pioctl("/the/target/file", cmd, &args, nofollow);

I would counter that with:

 (1) pioctl() is actually simpler and cleaner, and doesn't require
     modifications to open().

 (2) The open()/ioctl() method doesn't handle pathless pioctls, and so is not
     a complete solution.

 (3) The open()/ioctl() method assumes that pioctl() command numbers don't
     clash with ioctl() command numbers - something that's unfortunately not
     true of OpenAFS:-(

     Of course, you could have one ioctl() command number that says that this
     is a pioctl() and then a second number in the argument data that is the
     pioctl() command number.

 (4) pioctl() is compatible with OpenAFS.

Do you also disagree with OpenAFS's idea of creating a proc file to open so
that you can do ioctls on that to emulate pioctl()?  That would serve also.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/