Re: what's next for the linux kernel?

From: Luke Kenneth Casson Leighton (lkcl_at_lkcl.net)
Date: 10/06/05

  • Next message: John Zulauf: "Re: AMD Geode GX/LX support V2" 
    Date:	Thu, 6 Oct 2005 00:03:09 +0100
To: Horst von Brand <vonbrand@inf.utfsm.cl>

    On Wed, Oct 05, 2005 at 02:47:27PM -0400, Horst von Brand wrote:
    > Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
    > > 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.
    >
    > It's not an excuse, it's part of a coherent view of how things work. Just
    > as Netware used to have its, and DOS had its (sort of). As the world view
    > underneath Unix, it is darn hard to "fix".
    >
    > [This discussion sounds quite a lot like it is /you/ who needs "fixing",
    > i.e., first wrap your head around Unix' ways...]
     
     asking "ordinary" people to do that is unrealistic: surely you know
     that?
     
     i just spent two hours helping a friend who wasn't familiar
     with the concept of "give root password for maintenance or
     press ctrl-d" they'd been pressing ctrl-d because it said so
     and now i'm going to have a 5-hour round-trip journey and possibly
     an overnight stay to sort out the mess.

    > > selinux has already provided an alternative that is similar to NW
    > > file permissions.
    >
    > Nope. SELinux provides MAC,

     yes.

    > i.e., mechanisms by which system-wide policy
    > (not the random owner of an object) ultimately decides what operations to
    > allow.

     yes. the concept is not incompatible with what i said: the only bit
     that is wrong with what you've said is the word "Nope".

    > That is not "file permissions".

     part of the coverage of the MAC is file and directory permissions, and
     as i mentioned earlier, it so happens that each selinux permission
     corresponds, i believe one-to-one, with a function in the dnode and
     inode vfs higher-order-function tables in the linux kernel.

     example permissions (from postfix.te, policy source version 18):

            allow postfix_$1_t { sbin_t bin_t }:dir r_dir_perms;
            allow postfix_$1_t { bin_t usr_t }:lnk_file { getattr read };
            allow postfix_$1_t shell_exec_t:file rx_file_perms;

     i am confident enough with selinux to say that those are file
     and directory permissions.

     (r_dir_perms is a macro that expands to directory read
     permissions { read getattr lock search ioctl }, and
     rx_file_perms is a macro that expands to { read getattr lock
     execute ioctl })

     what this is saying is that postfix_$whatever_t context is
     allowed to read the contents of /sbin and /bin; it's also
     allowed to know if symlinks in /bin and /usr actually exist,
     and also allowed to follow those symlinks; and it's also allowed to
     know if shell-scripts exist, and also to read and ultimately
     execute them.

    > And yes, this is quite un-Unix-like.

     this is a good thing.

    > [...]
    >
    > > in what way is it possible for linux to fully support the NTFS
    > > filesystem?
    >
    > If you ask me, preferably not at all, just let that unholy mess quietly go
    > the way of the dinosaurs. Sadly, interoperability is required at times,
    > so...

     *sigh*, tell me about it. well, when reactos gets its NTFS driver, i
     will be sure to let you know. i promise :)

     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/

  • Next message: John Zulauf: "Re: AMD Geode GX/LX support V2"

    Relevant Pages

    • RE: [PHP] (SOLVED) /etc/php.init changes not honored
      ... The problem turned out to be selinux. ... Access Control (MAC, enhanced permissions using contexts). ... Create a file with the right permissions / context. ... In phpinfo() output, PHP tells you where it is looking for its php.ini ...
      (php.general)
    • Re: Fw: [PATCH 2.6.16-rc1-git4] accessfs: a permission managing filesystem
      ... > Accessfs is a permission managing filesystem. ... based on file permissions. ... The kernel already a mechanism for implementing extended security ... With SELinux we see a lot of these userspace assumptions, ...
      (Linux-Kernel)
    • Re: A great article on why to use SeLinux
      ... a command line tool to do this; I am not sure about a GUI tool. ... Windows converts are complaining about "those stupid permissions thing", ... Old-school Linux people are complaining about "that stupid selinux ... need to do the same for chcon. ...
      (Fedora)
    • Re: whats next for the linux kernel?
      ... >> selinux has already provided an alternative that is similar to NW ... >> file permissions. ... server to write some selinux policy files because POSIX filepermissions ... if i was to agree with you, it would be that the linux filesystem ...
      (Linux-Kernel)
    • Re: SELinux -- another view ?
      ... I started with man selinux, and read on what was suggested in the "see also" ... Think of it as an extension to the concept of permissions. ... That would be analogous to using the root account for regular work, ... avoid problems when "permissions denied" message appears to an ordinary user ...
      (Fedora)