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: <alpine.LFD.2.01.0906240933540.3240@localhost.localdomain>
Date:	Wed, 24 Jun 2009 09:40:42 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...IV.linux.org.uk>
cc:	David Howells <dhowells@...hat.com>,
	Miklos Szeredi <miklos@...redi.hu>, alan@...rguk.ukuu.org.uk,
	hch@...radead.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, adilger@....com,
	akpm@...ux-foundation.org
Subject: Re: [RFC] O_NOACC: open without any access



On Wed, 24 Jun 2009, Al Viro wrote:
> 
> i_filesystem_fop is certainly bogus, but why do we want to bother with
> file_operations at all?
> 
> Unless you really insist on unlimited use of ioctl(2) on such beasts (and
> any users will be non-portable for obvious reasons anyway), there's no need
> to go anywhere near ->open() *or* ->f_op in general.

A lot of filesystems (especially network filesystems) want to do something 
special when you open a node on them.

NFS, for example, does that whole alloc_nfs_open_context() thing to keep 
track of RPC credentials etc. It's where things like "filp->f_private" 
get set etc.

So if you don't call open(), you'll not initialize the filp sufficiently 
to do lots of operations.

But yes:

> Just add new methods to ->i_op (and we already have that coming from
> fs code) and teach do_filp_open() to
> 	* call permission() with new flag (MAY_TALK_TO_FS_NODE) for such
> open()
> 	* do not die with -ELOOP on symlinks if we have O_NOFOLLOW + your flag
> 	* do not call ->f_op->open() at all for such open()
> and we are all set.  Hell, we can even teach sys_ioctl() that given set
> of ioctls maps to calls of our new methods.  Taken from ->i_op...

Sure. That will work, but I do think that it's going to be more hacky than 
just trying to make the file descriptor look as real as possible, and just 
calling "open" on it.

But I don't really have any strong opinions.

		Linus
--
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/