Re: what's next for the linux kernel?

[Luke Kenneth Casson Leighton <lkcl@lkcl.net>]

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/