linux-kernel - Re: [patch 04/14] gfs2: dont call permission()

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 for Android: free password hash cracker in your pocket

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

Message-Id: <E1JzV1K-0001m8-SN@pomaz-ex.szeredi.hu>
Date:	Fri, 23 May 2008 13:01:10 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	swhiteho@...hat.com
CC:	miklos@...redi.hu, hch@...radead.org,
	linux-fsdevel@...r.kernel.org, viro@...IV.linux.org.uk,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 04/14] gfs2: dont call permission()

> Given the fact that (a) its only a very minor change and (b) as soon as
> we have a solution to what we really want to do:
> 
>  - inode/file operation:
>    - Do lookup via VFS
>    - Get GFS2 glock
>      - Do perm check via VFS
>      - Do actual operation
>    - Drop GFS2 glock

Well, fuse/nfs already do something similar, except they have their
actual permission checking in the server, as opposed to the vfs.  They
basically do:

 ->permission() does nothing

 ->foo_operation() does everything, including permission checking

The reality is a bit more complicated, and both nfs and fuse do
sometimes check permissions in ->permission() but most of the cases,
when they know that the permission will be checked later anyway they
just omit it.

Of course this would mean, that for example the LSM security checks
are not done within the gfs locked region.  Does that matter?

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