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] [day] [month] [year] [list]
Message-ID: <CAJfpeguhZLQWz4bvyJoaB2BLkzu2Op68_woUaBts2tCqECndcQ@mail.gmail.com>
Date:	Mon, 18 Mar 2013 12:27:15 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Robo Bot <apw@...onical.com>, Felix Fietkau <nbd@...nwrt.org>,
	Neil Brown <neilb@...e.de>,
	Jordi Pujol <jordipujolp@...il.com>, ezk@....cs.sunysb.edu,
	David Howells <dhowells@...hat.com>,
	Sedat Dilek <sedat.dilek@...glemail.com>,
	"J. R. Okajima" <hooanon05@...oo.co.jp>
Subject: Re: [PATCH 00/13] overlay filesystem: request for inclusion (v16)

On Thu, Mar 14, 2013 at 11:59 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> Huh?
>         * from st_mode point of view, it's not going to conflict with
> anything; FFS "entry type" matches bits 12..15 of mode_t, and the value
> picked by whoever had first implemented whiteouts had been chosen so
> that it would not clash with any existing values.  We have
> #define S_IFMT  00170000
> #define S_IFSOCK 0140000
> #define S_IFLNK  0120000
> #define S_IFREG  0100000
> #define S_IFBLK  0060000
> #define S_IFDIR  0040000
> #define S_IFCHR  0020000
> #define S_IFIFO  0010000
> and this sucker would've been 0160000; new filesystem object types are not
> frequently introduced, to put it mildly, so I wouldn't expect clashes.

I'm worried exactly because new filetypes are introduced so
infrequently.  No such thing happened during the lifetime of Linux,
AFAICT.  Backup/restore tools are not going to handle it.  File
managers are not going to show anything sane (and quite possibly some
will simply crash).

Yes, all that can be fixed, but it will be a slow and painful process,
since union/overlay type filesystems are themselves quite specialized
and problems are not going to be shaken out quickly with userspace
interaction.  On the other hand if a whiteout is exported to userspace
as a symlink with xattrs, there will be much less of those problems.

BTW I'm not against adding whiteout support to the VFS and possibly to
filesystems to clean up the security uglilness and optimize storage.

But I think the most important aspect is the userspace interface and
I'm far from sure that a new filetype is the best solution here.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ