On Aug 15, 2007, at 13:19:16, Marc Perkel wrote:
One of the problems with the Unix/Linux world is that your minds
are locked into this one model. In order to do it right it requires
the mental discipline to break out of that.
The major thing that you are missing is that this "one model" has
Kyle Moffett wrote:
Going even further in this direction, the following POSIX ACL on the
directories will do what you want:
## Note: file owner and group are kmoffett
u::rw-
g::rw-
u:lsorens:rw-
u:mtharp:rw-
u:mperkel:rw-
g:randomcvsdudes:r-
default:u::rw-
default:g::rw-
default:u:lsorens
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Aug 15, 2007, at 13:09:31, Marc Perkel wrote:
> > The idea is that people have permissions - not
> files. By people I
> > mean users, groups, managers, applications
> > etc. One might even specify that there are no
> permission
> >
Marc Perkel wrote:
> That not a problem - it's a feature. In such a
> situation the person would get a general file creation
> error.
Feature or not, it's still vulnerable to probing by malicious users. If
there are create permissions on the directory, the invisibility is not
perfect.
> Although
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
.
>
> > The important point here is that directories don't
> really exist.
>
> Except they do, and without directories the
> performance of your
> average filesystem is going to suck.
>
Actually you would get a speed improvement. You hash
the full
On Aug 15, 2007, at 13:09:31, Marc Perkel wrote:
The idea is that people have permissions - not files. By people I
mean users, groups, managers, applications
etc. One might even specify that there are no permission
restrictions at all. Part of the process would be that the kernel
load what
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Aug 15, 2007, at 12:02:41, Marc Perkel wrote:
> > Kyle, thinking further outside the box, files
> would no longer have
> > owners or permissions. Nor would
> > directories. People, groups, managers, and other
> objects with have
> >
One note before you read the rest of this:
The kinds of things you are discussing here are usually called
"MAC" or "Mandatory Access Control", and they are always implemented
on top of an LSM *after* ordinary "DAC" or "Discretionary Access
Control" (IE: file permissions) are applied. If
--- [EMAIL PROTECTED] wrote:
> On Wed, 15 Aug 2007 09:02:41 PDT, Marc Perkel said:
>
> > Kyle, thinking further outside the box, files
> would no
> > longer have owners or permissions. Nor would
> > directories. People, groups, managers, and other
> > objects with have permissions.
>
> You
--- alan <[EMAIL PROTECTED]> wrote:
> On Tue, 14 Aug 2007, Marc Perkel wrote:
>
> > For example. If you list a directory you only see
> the
> > files that you have some rights to and files where
> you
> > have no rights are invisible to you. If a file is
> read
> > only to you then you can't
On Wed, 15 Aug 2007 09:02:41 PDT, Marc Perkel said:
> Kyle, thinking further outside the box, files would no
> longer have owners or permissions. Nor would
> directories. People, groups, managers, and other
> objects with have permissions.
You gotta think *way* out of the box to come up with a
On Aug 15, 2007, at 12:02:41, Marc Perkel wrote:
Kyle, thinking further outside the box, files would no longer have
owners or permissions. Nor would
directories. People, groups, managers, and other objects with have
permissions. One might tag a file with the object that created it
so you
--- Michael Tharp <[EMAIL PROTECTED]> wrote:
> 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
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
>
> ## Note: file owner and group are kmoffett
> u::rw-
> g::rw-
> u:lsorens:rw-
> u:mtharp:rw-
> u:mperkel:rw-
> g:randomcvsdudes:r-
> default:u::rw-
> default:g::rw-
> default:u:lsorens
> default:u:mtharp:rw-
> default:u:mperkel:rw-
>
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
On Aug 15, 2007, at 09:30:21, Lennart Sorensen wrote:
On Wed, Aug 15, 2007 at 09:02:37AM -0400, Michael Tharp wrote:
Personally, what I'd like to see is a better way of dealing with
propagation of ownership. Currently, in order to allow
"collaboration" directories where a directory tree is
On Wed, Aug 15, 2007 at 09:02:37AM -0400, Michael Tharp wrote:
> This jumped out at me right away. In such a system, an attacker with
> write permissions on a "sticky" directory like /tmp could probe for
> others' files by attempting to create them and recording all cases where
> permission was
alan wrote:
> Imagine the fun you will have trying to write a file name and being told
> you cannot write it for some unknown reason. Unbeknownst to you, there
> is a file there, but it is not owned by you, thus invisible.
This jumped out at me right away. In such a system, an attacker with
The ACLs that were added to Linux were a step in the
right direction but very incomplete. What should be is
a complex permission system that would allow fine
grained permissions and inherentance masks to control
what permission are granted when someone moves new
files into a directory. Instead of
The ACLs that were added to Linux were a step in the
right direction but very incomplete. What should be is
a complex permission system that would allow fine
grained permissions and inherentance masks to control
what permission are granted when someone moves new
files into a directory. Instead of
alan wrote:
Imagine the fun you will have trying to write a file name and being told
you cannot write it for some unknown reason. Unbeknownst to you, there
is a file there, but it is not owned by you, thus invisible.
This jumped out at me right away. In such a system, an attacker with
write
On Aug 15, 2007, at 09:30:21, Lennart Sorensen wrote:
On Wed, Aug 15, 2007 at 09:02:37AM -0400, Michael Tharp wrote:
Personally, what I'd like to see is a better way of dealing with
propagation of ownership. Currently, in order to allow
collaboration directories where a directory tree is
On Wed, Aug 15, 2007 at 09:02:37AM -0400, Michael Tharp wrote:
This jumped out at me right away. In such a system, an attacker with
write permissions on a sticky directory like /tmp could probe for
others' files by attempting to create them and recording all cases where
permission was denied
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
--- Kyle Moffett [EMAIL PROTECTED] wrote:
## Note: file owner and group are kmoffett
u::rw-
g::rw-
u:lsorens:rw-
u:mtharp:rw-
u:mperkel:rw-
g:randomcvsdudes:r-
default:u::rw-
default:g::rw-
default:u:lsorens
default:u:mtharp:rw-
default:u:mperkel:rw-
default:g:randomcvsdudes:r-
--- Michael Tharp [EMAIL PROTECTED] wrote:
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
On Wed, 15 Aug 2007 09:02:41 PDT, Marc Perkel said:
Kyle, thinking further outside the box, files would no
longer have owners or permissions. Nor would
directories. People, groups, managers, and other
objects with have permissions.
You gotta think *way* out of the box to come up with a
On Aug 15, 2007, at 12:02:41, Marc Perkel wrote:
Kyle, thinking further outside the box, files would no longer have
owners or permissions. Nor would
directories. People, groups, managers, and other objects with have
permissions. One might tag a file with the object that created it
so you
--- alan [EMAIL PROTECTED] wrote:
On Tue, 14 Aug 2007, Marc Perkel wrote:
For example. If you list a directory you only see
the
files that you have some rights to and files where
you
have no rights are invisible to you. If a file is
read
only to you then you can't delete it either.
--- [EMAIL PROTECTED] wrote:
On Wed, 15 Aug 2007 09:02:41 PDT, Marc Perkel said:
Kyle, thinking further outside the box, files
would no
longer have owners or permissions. Nor would
directories. People, groups, managers, and other
objects with have permissions.
You gotta think
One note before you read the rest of this:
The kinds of things you are discussing here are usually called
MAC or Mandatory Access Control, and they are always implemented
on top of an LSM *after* ordinary DAC or Discretionary Access
Control (IE: file permissions) are applied. If your MAC
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Aug 15, 2007, at 12:02:41, Marc Perkel wrote:
Kyle, thinking further outside the box, files
would no longer have
owners or permissions. Nor would
directories. People, groups, managers, and other
objects with have
permissions. One might
On Aug 15, 2007, at 13:09:31, Marc Perkel wrote:
The idea is that people have permissions - not files. By people I
mean users, groups, managers, applications
etc. One might even specify that there are no permission
restrictions at all. Part of the process would be that the kernel
load what
--- Phillip Susi [EMAIL PROTECTED] wrote:
Kyle Moffett wrote:
Going even further in this direction, the
following POSIX ACL on the
directories will do what you want:
## Note: file owner and group are kmoffett
u::rw-
g::rw-
u:lsorens:rw-
u:mtharp:rw-
u:mperkel:rw-
On Aug 15, 2007, at 13:34:44, Phillip Susi wrote:
The problem that I have with this setup is that it specifies an ACL
on EACH file. Yes, you can set a default on the directory for
newly created files, but what if I want to add a user to the access
list for that whole directory? I have to
On Aug 15, 2007, at 13:19:16, Marc Perkel wrote:
One of the problems with the Unix/Linux world is that your minds
are locked into this one model. In order to do it right it requires
the mental discipline to break out of that.
The major thing that you are missing is that this one model has
Marc Perkel wrote:
That not a problem - it's a feature. In such a
situation the person would get a general file creation
error.
Feature or not, it's still vulnerable to probing by malicious users. If
there are create permissions on the directory, the invisibility is not
perfect.
Although it
--- Kyle Moffett [EMAIL PROTECTED] wrote:
.
The important point here is that directories don't
really exist.
Except they do, and without directories the
performance of your
average filesystem is going to suck.
Actually you would get a speed improvement. You hash
the full name and
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Aug 15, 2007, at 13:09:31, Marc Perkel wrote:
The idea is that people have permissions - not
files. By people I
mean users, groups, managers, applications
etc. One might even specify that there are no
permission
restrictions at all.
Kyle Moffett wrote:
Going even further in this direction, the following POSIX ACL on the
directories will do what you want:
## Note: file owner and group are kmoffett
u::rw-
g::rw-
u:lsorens:rw-
u:mtharp:rw-
u:mperkel:rw-
g:randomcvsdudes:r-
default:u::rw-
default:g::rw-
default:u:lsorens
--- Michael Tharp [EMAIL PROTECTED] wrote:
Marc Perkel wrote:
That not a problem - it's a feature. In such a
situation the person would get a general file
creation
error.
Feature or not, it's still vulnerable to probing by
malicious users. If
there are create permissions on the
Kyle,
In this new system setfacl, chmod, chown, and chgrp
all go away except inside of an emulation layer. File
and directories no longer have permissions. People
have permission to naming patterns. So if you put a
file into a tree or move a tree then those who have
permissions to the tree have
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Aug 15, 2007, at 13:19:16, Marc Perkel wrote:
One of the problems with the Unix/Linux world is
that your minds
are locked into this one model. In order to do it
right it requires
the mental discipline to break out of that.
The major
On Aug 15, 2007, at 14:05:23, Marc Perkel wrote:
In this new system setfacl, chmod, chown, and chgrp all go away
except inside of an emulation layer. File and directories no longer
have permissions. People have permission to naming patterns. So if
you put a file into a tree or move a tree
HI
While I find your ideas intriguing, I'd like to offer a friendly
suggestion: You're never going to convince anyone on LKML unless you do
the following things:
* Describe your idea in detail, including algorithms, pseudo code,
pictures, or whatever. Vague hand-wavey stuff won't do it.
On Wed, Aug 15, 2007 at 10:30:19AM -0700, Marc Perkel wrote:
--- Kyle Moffett [EMAIL PROTECTED] wrote:
Except they do, and without directories the
performance of your average filesystem is going to suck.
Actually you would get a speed improvement. You hash
the full name and get the file
On Wed, Aug 15, 2007 at 10:59:12AM -0700, Marc Perkel wrote:
When one thinks outside the box one has to think about
evolving beyond what you are used to. When I moved
beyond DOS I have to give up the idea of 8.3 file
names. The idea here is to come up with a model that
can emulate the
On Wed, Aug 15, 2007 at 10:09:31AM -0700, Marc Perkel wrote:
Yep - way outside the box - and thus the title of the
thread.
The idea is that people have permissions - not files.
By people I mean users, groups, managers, applications
etc. One might even specify that there are no
permission
On 8/15/07, Marc Perkel [EMAIL PROTECTED] wrote:
I want to throw out some concepts about a new way of
thinking about file systems. But the first thing you
have to do is to forget what you know about file
systems now. This is a discussion about a new view of
looking a file storage that is
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Aug 15, 2007, at 14:05:23, Marc Perkel wrote:
In this new system setfacl, chmod, chown, and
chgrp all go away
except inside of an emulation layer. File and
directories no longer
have permissions. People have permission to naming
On Aug 15, 2007, at 15:26:07, Lennart Sorensen wrote:
On Wed, Aug 15, 2007 at 10:59:12AM -0700, Marc Perkel wrote:
When one thinks outside the box one has to think about evolving
beyond what you are used to. When I moved
beyond DOS I have to give up the idea of 8.3 file names. The idea
here
--- Craig Ruff [EMAIL PROTECTED] wrote:
On Wed, Aug 15, 2007 at 10:30:19AM -0700, Marc
Perkel wrote:
--- Kyle Moffett [EMAIL PROTECTED] wrote:
Except they do, and without directories the
performance of your average filesystem is going
to suck.
Actually you would get a speed
Kyle Moffett wrote:
We've *always* had to do this; that's what chmod -R or setfacl -R
are for :-D. The major problem is that the locking and lookup overhead
gets really significant if you have to look at the entire directory tree
in order to determine the permissions for one single object. I
Marc Perkel wrote:
Kyle - you are still missing the point. chmod goes
away. File permissions goes away. Directories as you
know them goes away.
You are missing the point Marc... open()ing a file will have to perform
a number of these pattern matches to decide if it is allowed or not...
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Aug 15, 2007, at 15:26:07, Lennart Sorensen
wrote:
On Wed, Aug 15, 2007 at 10:59:12AM -0700, Marc
Perkel wrote:
When one thinks outside the box one has to think
about evolving
beyond what you are used to. When I moved
beyond DOS I have
--- Phillip Susi [EMAIL PROTECTED] wrote:
Marc Perkel wrote:
Kyle - you are still missing the point. chmod goes
away. File permissions goes away. Directories as
you
know them goes away.
You are missing the point Marc... open()ing a file
will have to perform
a number of these
On Wed, Aug 15, 2007 at 01:44:50PM -0700, Marc Perkel wrote:
Yes - that's a good example. Git is far more powerful
and a different paradigm for CVS. Someone had to think
outside the box and come up with a new way of looking
at things. I'm trying to do something like that with
this idea.
To
On Wed, 15 Aug 2007 13:50:17 PDT, Marc Perkel said:
I don't see it as being any worse that what we have
now. To open a file you have to start at the bottom
and open each directory and evaluate the permissions
on the way to the file. In my system you have to look
up the permission of the
Al Viro added to the CC, since he's one of the experts on this stuff
and will probably whack me with a LART for explaining it all wrong,
or something. :-D
On Aug 15, 2007, at 16:38:36, Phillip Susi wrote:
Kyle Moffett wrote:
We've *always* had to do this; that's what chmod -R or setfacl -
Kyle Moffett wrote:
I am well aware of that, I'm simply saying that sucks. Doing a
recursive chmod or setfacl on a large directory tree is slow as all hell.
Doing it in the kernel won't make it any faster.
Right... I'm talking about getting rid of it entirely.
You can't safely preserve
--- Kyle Moffett [EMAIL PROTECTED] wrote:
Al Viro added to the CC, since he's one of the
experts on this stuff
and will probably whack me with a LART for
explaining it all wrong,
or something. :-D
Thanks - I appreciate that.
Just to catch everyone up on what this thread is
about,
--- [EMAIL PROTECTED] wrote:
On Wed, 15 Aug 2007 13:50:17 PDT, Marc Perkel said:
I don't see it as being any worse that what we
have
now. To open a file you have to start at the
bottom
and open each directory and evaluate the
permissions
on the way to the file. In my system you have
On Wed, 15 Aug 2007 15:48:15 PDT, Marc Perkel said:
Consider the rules:
peter '*a*' can create
peter '*b*' cannot create
Peter tries to create 'foo-ab-bar' - is he allowed
to or not?
First - I'm proposing a concept, not writing the
implementation of the concept. You are
Mmm, slow-as-dirt hotel wireless. What fun...
On Aug 15, 2007, at 18:14:44, Phillip Susi wrote:
Kyle Moffett wrote:
I am well aware of that, I'm simply saying that sucks. Doing a
recursive chmod or setfacl on a large directory tree is slow as
all hell.
Doing it in the kernel won't make
On Tue, 14 Aug 2007, Marc Perkel wrote:
For example. If you list a directory you only see the
files that you have some rights to and files where you
have no rights are invisible to you. If a file is read
only to you then you can't delete it either. Having
write access to a directory really
I want to throw out some concepts about a new way of
thinking about file systems. But the first thing you
have to do is to forget what you know about file
systems now. This is a discussion about a new view of
looking a file storage that is radically different and
it's more easily undersood if you
I want to throw out some concepts about a new way of
thinking about file systems. But the first thing you
have to do is to forget what you know about file
systems now. This is a discussion about a new view of
looking a file storage that is radically different and
it's more easily undersood if you
On Tue, 14 Aug 2007, Marc Perkel wrote:
For example. If you list a directory you only see the
files that you have some rights to and files where you
have no rights are invisible to you. If a file is read
only to you then you can't delete it either. Having
write access to a directory really
101 - 168 of 168 matches
Mail list logo
