linux-kernel - Re: [PATCH 0/7] overlay filesystem: request for inclusion

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: <87hb7piwrl.fsf@tucsk.pomaz.szeredi.hu>
Date:	Thu, 16 Jun 2011 18:09:02 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	"J. R. Okajima" <hooanon05@...oo.co.jp>
Cc:	Erez Zadok <ezk@....cs.sunysb.edu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"viro\@ZenIV.linux.org.uk Viro" <viro@...IV.linux.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	apw@...onical.com, nbd@...nwrt.org, neilb@...e.de,
	hramrach@...trum.cz, jordipujolp@...il.com
Subject: Re: [PATCH 0/7] overlay filesystem: request for inclusion

"J. R. Okajima" <hooanon05@...oo.co.jp> writes:

>> over the years developing a standalone stackable file system based =
>> approach.  These approaches were rejected largely due to their =
> 	:::
>> location for this functionality.  There is some merit to a VFS based =
>> approach: unioning performs a fair amount of namespace manipulation =
>> (merging directories, eliminating duplications, whiteouts and opaques, =
>> etc.), and the VFS is often best suited for complex namespace =
>> operations.
>
> Exactly.
> I understand everybody likes simpler patch, and I have no objection to
> merge UnionMount into mainline. But this union-type-mount approach has
> some demerit which I have posted before. Those are inherited by
> overlayfs too, and Miklos called it "unPOSIXy behavior". I think the
> most part of the cause of these behaviour came from its design or
> architecture.

Yes, overlayfs shares some of the basic architecture of union-mounts.
The most important such property is that when a file is copied up, it's
like replacing the file with a new one:

   cp /foo/bar /tmp/ttt
   mv -f /tmp/ttt /foo/bar

Which is exactly the thing that some editors do when saving a modified
file, so most applications should handle this behavior fine.  The truth
is a bit more complicated and the effect of the copy-up is more like
this:

   cp /foo/bar /tmp/ttt
   mount --bind /tmp/ttt /foo/bar

> Additionally the number of members may be important too. Overlayfs
> supports only two members currently. When a user wants more layers,
> he has to mount another overlayfs over overlayfs. Since it is
> essentially equivalent to a recursive function call internally, and of
> course the stack size in kernel space is limited, I don't think it is
> good.

Good point about stack space.

Adding multiple read-only layers should be really easy, and could be one
of the first extensions after the merge.

> Also Miklos replied and said modifying the credentials internally does
> no harm to other threads. But I am still afraid it a security hole since
> the credentials is shared among threads. If I had time, I would test it
> by myself.

The credentials of the current task are not modified but replaced by
new, temporary credentials.  This will only have an affect on a single
thread.

Thanks,
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/