linux-kernel - Re: [RFC] O_NOACC: open without any access

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: <17246.1245776356@redhat.com>
Date:	Tue, 23 Jun 2009 17:59:16 +0100
From:	David Howells <dhowells@...hat.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	dhowells@...hat.com, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	viro@...IV.linux.org.uk, adilger@....com, alan@...rguk.ukuu.org.uk,
	akpm@...ux-foundation.org
Subject: Re: [RFC] O_NOACC: open without any access

Miklos Szeredi <miklos@...redi.hu> wrote:

> Not sure if it's a good base for what AFS/pioctl is trying to do, but
> it's something that I personally would very much like to see.

It could be useful.  The problem is that I then need to do an ioctl() on it.

To emulate a pioctl with this, I'd need something like the following in a
library:

	long pioctl(char *path, int cmd, struct ViceIoctl *arg, int nofollow)
	{
		struct ioctl_pioctl {
			int cmd;
			struct ViceIoctl *arg;
		} ip;
		long ret;
		int fd;

		switch (cmd) {
		case VIOC_CMD1:
		case VIOC_CMD2:
		case VIOC_CMD3:
			fd = open(path, O_NOACC | (nofollow ? O_NOFOLLOW : 0));
			ip.cmd = cmd;
			ip.arg = arg;
			ret = ioctl(fd, DO_PIOCTL, &ip);
			close(fd);
			break;
		}

		return ret;
	}

Now, the DO_PIOCTL constant could be dispensed with, and each VIOC_CMDx be
mapped to a different ioctl command number.  Note that you may not assume that
the set of pioctl numbers shares with the set of ioctl numbers, so you can't
just hand the cmd number through as-is.

Not all pioctl commands need to be emulated this way.  Some could call getxattr
instead, for instance, and some could muck around with /proc and /sys files.

>   2) open with "3" calls driver's ->open() with any side effect that
>      may have.  Open with O_NOACC doesn't do that, and hence if we
>      want to allow ioctls they need a new interface which gets a
>      "struct path" instead of a "struct file".

You don't actually need that.  struct file contains a struct path.  You just
need a way to come up with an alternative set of file ops for an O_NOACC open
- perhaps through struct inode_operations.

Alternatively, you could install a special set of generic file ops that only
has an ioctl op.  This could then redirect through another ioctl op in the
inode_operations struct.

As I mentioned in another email, for emulation of pioctl(), I need O_NOACC to
_not_ call device_driver->open() on device files, and to not install the
device driver file ops table.  pioctl() operates on the underlying file in the
underlying fs.

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/