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]
Date:	Wed, 15 Aug 2007 11:14:33 -0400
From:	Michael Tharp <gxti@...tiallystapled.com>
To:	Kyle Moffett <mrmacman_g4@....com>
CC:	alan <alan@...eserver.org>, Marc Perkel <mperkel@...oo.com>,
	LKML Kernel <linux-kernel@...r.kernel.org>,
	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>
Subject: Re: Thinking outside the box on file systems

Kyle Moffett wrote:
> Basically any newly-created item in such a directory will get the
> permissions described by the "default:" entries in the ACL, and
> subdirectories will get a copy of said "default:" entries.

This would work well, although I would give write permissions to a group
so the entire dir wouldn't need to be re-ACLed when a user is added. I
may give this a shot; I've been avoiding ACLs because they have always
sounded incomplete/not useful, but the inheritance aspect sounds rather
nice.

> So yes, such functionality is nice; even more so because we already have
> it.  I think if you were really going to "extend" a UNIX filesystem it
> would need to be in 2 directions:
>   (A)  Handling disk failures by keeping multiple copies of important
> files.

This is ZFS' bailiwick, no? I'd love to see the licensing issues
resolved, because if it can control level of redundancy on a
per-file/directory basis, I would be a very happy man.

>   (B)  Have version-control support

This might be pushing it, but hey, we *are* talking about the future here.

>   (C)  Allowing distributed storage (also lazy synchronization and
> offline modification support)

I'd really love to see distributed storage not suck. Everything I've
seen requires myriad daemons and ugly configuration.

> With some appropriate modifications and hooks, GIT actually comes pretty
> close here.  For larger files it needs to use a "list-of-4MB-chunks"
> approach to minimize the computation overhead for committing a
> randomly-modified file.  The "index" of course would be directly read
> and modified by vfs calls and via mapped memory.  Merge handling would
> need careful integration, preferably with allowing custom
> default-merge-handlers per subtree.  There would be lots more design
> issues to work out, but it's something to think about

Now you're just being silly ;)

> Cheers,
> Kyle Moffett

-- m. tharp
-
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