lkml.org 
[lkml]   [2005]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: what's next for the linux kernel?
On Wed, Oct 05, 2005 at 02:30:44PM +0400, Nikita Danilov wrote:
> Luke Kenneth Casson Leighton writes:
> > On Wed, Oct 05, 2005 at 01:24:12PM +0400, Nikita Danilov wrote:
> >
> > > Marc Perkel writes:
> > >
> > > [...]
> > >
> > > > Right - that's Unix "inside the box" thinking. The idea is to make the
> > > > operating system smarter so that the user doesn't have to deal with
> > > > what's computer friendly - but reather what makes sense to the user.
> > > > From a user's perspective if you have not rights to access a file then
> > > > why should you be allowed to delete it?
> > >
> > > Because in Unix a name is not an attribute of a file.
> >
> > there is no excuse.
> >
> > selinux has already provided an alternative that is similar to NW
> > file permissions.
>
> That's exactly the point: Unix file system model is more flexible than
> alternatives.

*grin*. sorry - i have to disagree with you (but see below).

i was called in to help a friend of mine at EDS to do a bastion sftp
server to write some selinux policy files because POSIX filepermissions
could not fulfil the requirements.

the requirements were two-fold:

1) for an authorised uploader to be able to copy files into
a subdirectory but to be banned from seeing other files and
banned from overwriting or deleting anything - existing or
uploaded. once the file's there, it's there.

2) for an authorised downloader to be able to copy files _out_
of a subdirectory and to be able to delete those files but
to be banned from overwriting files, or modifying files,
or adding files to the subdirectory.

it is not possible to fulfil those requirements with POSIX - not even
POSIX ACLs not even messing about creating groups with different rwx
permissions.

however, selinux was, because you have separate permissions for
directories to create and remove names, read and write to the
directory, and separate permissions _again_ for files.

basically, i think (without checking) that there is one
selinux permission per each inode operation and per each
dnode operation totalling somewhere around thirty separate
selinux filesystem permissions, which is _much_ better than
the pathetic POSIX rwx and implicit directory rules stuff.

POSIX permissions were designed to fit into what... 16 bits,
so they didn't have a lot to play with.

if i was to agree with you, it would be that the linux filesystem
API is more flexible than the alternatives, most definitely not the
Unix filesystem model (if you believe that to be POSIX).

but the linux filesystem API i do not believe to be _as_ flexible as
say the NTFS filesystem API (or the Netware one, although i don't know
much about that one).

l.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-10-05 13:16    [W:0.226 / U:0.604 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site