[lkml]   [2011]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    On Fri, Aug 26, 2011 at 3:50 PM, Eric Paris <> wrote:
    > On Fri, Aug 26, 2011 at 1:52 AM, Jarkko Sakkinen
    > <> wrote:
    >> IOCTL call for /smack/load that takes access rule in
    >> the same format as they are written into /smack/load.
    >> Sets errno to zero if access is allowed and to EACCES
    >> if not.
    >> Signed-off-by: Jarkko Sakkinen <>
    > [SELinux maintainer here, but Casey knew to already take what I say
    > with a grain of salt]
    > I'm not telling you to do anything differently, just telling you what
    > SELinux does, and why we do it.  SELinux has a file in selinuxfs
    > called 'access.'  The file can be opened and one can write a rule into
    > the file.  One then calls read and gets back a structure which
    > contains all of the permissions information allowed for the
    > source/target/class.  In SELinux we calculate all of the permissions
    > for the tuple at once so providing all of the information at once can
    > make a lot of sense.  libselinux provides libraries that will cache
    > these decisions in the userspace program and quickly answer the same
    > (or similar) questions later.

    Thank you for this information. One thing that concerns
    me in this approach is the scenario where things serialize
    to the following sequence:

    - Process A does open()
    - Process B does open()
    - Process A does write()
    - Process B does write()
    - Process A does read()
    - ... (sequence continues)

    What's the end result?

    > Shows the userspace side of out "access" interface.  Your interface is
    > good in that it only takes 1 syscall and ours takes 2.  Your interface
    > is bad in that it is ioctl and we are told since birth that we must
    > hate them no matter what (not that read/write is really any
    > different).  It isn't the same method the only other LSM I know about
    > uses.  It can only every return one value (ok, I know ioctl can be
    > made to do anything at all)

    I'm aware of the fact that IOCTLs should be avoided
    but on the other hand in this use case I see it as the
    cleanest possible API that enables clean and simple
    user space support for access control and has least
    risk for any side-effects.

    > Anyway, just food for thought....
    > -Eric

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-08-26 18:07    [W:0.022 / U:108.736 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site