| 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
| ||
|
Message-ID: <8739ig3k93.fsf@tucsk.pomaz.szeredi.hu> Date: Fri, 08 Jul 2011 16:44:08 +0200 From: Miklos Szeredi <miklos@...redi.hu> To: "J. R. Okajima" <hooanon05@...oo.co.jp> Cc: Andrew Morton <akpm@...ux-foundation.org>, NeilBrown <neilb@...e.de>, viro@...IV.linux.org.uk, torvalds@...ux-foundation.org, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, apw@...onical.com, nbd@...nwrt.org, hramrach@...trum.cz, jordipujolp@...il.com, ezk@....cs.sunysb.edu Subject: Re: [PATCH 0/7] overlay filesystem: request for inclusion Miklos Szeredi <miklos@...redi.hu> writes: > "J. R. Okajima" <hooanon05@...oo.co.jp> writes: >> If I remember correctly, Miklos has mentioned about it like this. >> - overlayfs provides the same feature set as UnionMount. >> - but its implementation is much smaller and simpler than UnionMount. >> >> I agree with this argument (Oh, I have to confess that I don't test >> overlayfs by myself). But it means that overlayfs doesn't provide some >> features which UnionMount doesn't provide. I have posted about such >> features before, but I list them up again here. >> - the inode number may change silently. >> - hardlinks may corrupt by copy-up. >> - read(2) may get obsolete filedata (fstat(2) for metadata too). >> - fcntl(F_SETLK) may be broken by copy-up. >> - unnecessary copy-up may happen, for example mmap(MAP_PRIVATE) after >> open(O_RDWR). Here's a patch to document these limitations. Thanks, Miklos ---- Subject: ovl: add limitation to documentation From: Miklos Szeredi <mszeredi@...e.cz> J. R. Okajima noted some examples where overlayfs behaves differently from a standard filesystem. Describe these cases in the documentation. Reported-by: "J. R. Okajima" <hooanon05@...oo.co.jp> Signed-off-by: Miklos Szeredi <mszeredi@...e.cz> --- Documentation/filesystems/overlayfs.txt | 29 +++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) Index: linux-2.6/Documentation/filesystems/overlayfs.txt =================================================================== --- linux-2.6.orig/Documentation/filesystems/overlayfs.txt 2011-07-07 16:01:47.000000000 +0200 +++ linux-2.6/Documentation/filesystems/overlayfs.txt 2011-07-08 14:16:44.000000000 +0200 @@ -143,6 +143,9 @@ to the upper filesystem (copy_up). Note also requires copy_up, though of course creation of a symlink does not. +The copy_up may turn out to be unnecessary, for example if the file is +opened for read-write but the data is not modified. + The copy_up process first makes sure that the containing directory exists in the upper filesystem - creating it and any parents as necessary. It then creates the object with the same metadata (owner, @@ -156,6 +159,27 @@ filesystem - future operations on the fi overlay filesystem (though an operation on the name of the file such as rename or unlink will of course be noticed and handled). + +Non-standard behavior at copy_up +-------------------------------- + +The copy_up operation essentially creates a new, identical file and +moves it over to the old name. The new file may be on a different +filesystem, so both st_dev and st_ino of the file may change. + +Any open files referring to this inode will access the old data and +metadata. Similarly any file locks obtained before copy_up will not +apply to the copied up file. + +If a file with multiple hard links is copied up, then this will +"break" the link. Changes will not be propagated to other names +referring to the same inode. + +Symlinks in /proc/PID/ and /proc/PID/fd which point to a non-directory +object in overlayfs will not contain vaid absolute paths, only +relative paths leading up to the filesystem's root. This will be +fixed in the future. + Changes to underlying filesystems --------------------------------- @@ -163,5 +187,6 @@ Offline changes, when the overlay is not the upper or the lower trees. Changes to the underlying filesystems while part of a mounted overlay -filesystem are not allowed. This is not yet enforced, but will be in -the future. +filesystem are not allowed. If the underlying filesystem is changed, +the behavior of the overlay is undefined, though it will not result in +a crash or deadlock. -- 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