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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 17 Feb 2017 15:35:29 -0500 From: Vivek Goyal <vgoyal@...hat.com> To: James Bottomley <James.Bottomley@...senPartnership.com> Cc: Al Viro <viro@...IV.linux.org.uk>, Djalal Harouni <tixxdz@...il.com>, Chris Mason <clm@...com>, Theodore Tso <tytso@....edu>, Josh Triplett <josh@...htriplett.org>, "Eric W. Biederman" <ebiederm@...ssion.com>, Andy Lutomirski <luto@...nel.org>, Seth Forshee <seth.forshee@...onical.com>, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org, Dongsu Park <dongsu@...ocode.com>, David Herrmann <dh.herrmann@...glemail.com>, Miklos Szeredi <mszeredi@...hat.com>, Alban Crequy <alban.crequy@...il.com>, "Serge E. Hallyn" <serge@...lyn.com>, Phil Estes <estesp@...il.com> Subject: Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount On Fri, Feb 17, 2017 at 09:34:07AM -0800, James Bottomley wrote: > On Fri, 2017-02-17 at 02:55 +0000, Al Viro wrote: > > On Thu, Feb 16, 2017 at 07:56:30AM -0800, James Bottomley wrote: > > > > > > Hi James, > > > > > > > > Should it be "return d_splice_alias()" so that if we find an > > > > alias it is returned back to caller and passed in dentry can be > > > > freed. Though I don't know in what cases alias can be found. And > > > > if alias is found how do we make sure alias_dentry->d_fsdata is > > > > pointing to new (real dentry). > > > > > > It probably should be for the sake of the pattern. In our case I > > > don't think we can have any root aliases because the root dentry is > > > always pinned in the cache, so cache lookup should always find it. > > > > What does that have to do with root dentry? The real reason why that > > code works (FVerySVO) is that the damn thing allocates a new inode > > every time. Including the hardlinks, BTW. > > Yes, this is a known characteristic of stacked filesystems. Is there > some magic I don't know about that would make it easier to reflect hard > links as aliases? I think overlayfs had the same issue in the beginning and miklos fixed it. commit 51f7e52dc943468c6929fa0a82d4afac3c8e9636 Author: Miklos Szeredi <mszeredi@...hat.com> Date: Fri Jul 29 12:05:24 2016 +0200 ovl: share inode for hard link Vivek
Powered by blists - more mailing lists