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
| ||
|
Date: Thu, 24 Apr 2008 16:36:38 +0200 From: Miklos Szeredi <miklos@...redi.hu> To: viro@...IV.linux.org.uk CC: miklos@...redi.hu, akpm@...ux-foundation.org, torvalds@...ux-foundation.org, dave@...ux.vnet.ibm.com, ezk@...sunysb.edu, mhalcrow@...ibm.com, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [patch 00/13] vfs: add helpers to check r/o bind mounts > > > fh_verify() doesn't modify. > > > It does check, though, and later we have that check duplicated by > > > will_write/wont_write pair bracketing a part of sequence. > > > > So what? All the other checks are also duplicated within > > vfs_create()->may_create()->permission(). > > RTFS. permission() doesn't do "is that vfsmount read-only" checks, exactly > because it's 100% bogus - either you cover it with entire area where we > are guaranteed to stay r/w, or it's by definition racy. I know that. That does not mean, that fh_verify() needs to do vfsmount r/o checks. AFAICS it's perfectly OK to do that later, around the vfs_ call. > > > ecryptfs should not use the bloody vfsmount, for fuck sake! You are > > > confusing access to fs with access to fs via specific vfsmount. And > > > pretending that the latter is fundamental operation. > > > > Umm, isn't it? Want to redo open() without a vfsmount? > > FWIW, I'm not all that happy about the way ecryptfs_interpose() is done, > while we are at it. We get the sucker opened by whoever steps on given > place in the tree first, with subsequent operations done using the resulting > struct file. With fallback to r/o open. What happens to somebody who > tries to open it with enough permissions to do r/w? You are digressing from the subject. Yes it would be nice to fix ecryptfs to be less broken. But that's not what this patchset is set out to do. 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/
Powered by blists - more mailing lists