lkml.org 
[lkml]   [2009]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [patch 00/13] devtmpfs patches
    From
    Date
    On Mon, 2009-05-11 at 23:05 +0200, Kay Sievers wrote:
    > On Mon, May 11, 2009 at 22:41, David P. Quigley <dpquigl@tycho.nsa.gov> wrote:
    >
    > > This however does highlight a problem with the fact that device node
    > > labeling isn't being done properly. It should be possible to create this
    > > fs with a different name such that it doesn't appear as a tmpfs file
    > > system to SELinux. If it appears as a devtmpfs file system then we can
    > > specify the root label and labels on the other devices properly in
    > > policy.
    >
    > That could be done, if it solves this problem. Damn, now we have the
    > naming problem back again. :)
    >
    > By doing its own fstype, we could also make the auto-mount optional,
    > because you could always reach the filesystem anytime later.
    >
    > A different fstype has the slight inconvenience, that existing
    > userspace needs to be taught to handle it explicitly, while a tmfps is
    > already handled automatically because we use tmpfs already today. But
    > that may not be too important.
    >
    > Thanks a lot for your tests and analysis,

    I don't think merely changing the fstype will suffice; that merely lets
    us assign a different default security context to inodes in the
    filesystem (e.g. device_t vs tmpfs_t), but doesn't address the fact that
    use of devtmpfs rather than just udev seems to alter the permission
    checking upon an open(2) by mingetty, thereby breaking existing
    policies. Previously mingetty didn't require permissions to mknod; with
    devtmpfs, it does. I'm wondering if devtmpfs is internally performing
    operations that ought to be done in kernel context rather than the
    context of the userspace process that initiated the open(2).

    Also, I was wondering why the existing restorecon -R /dev that is
    performed by /etc/rc.sysinit to fix up the security contexts on the
    initial /dev tree prior to policy load doesn't seem to be getting
    applied when devtmpfs is enabled. Does devtmpfs pass through setxattr()
    requests to the underlying tmpfs mount?

    --
    Stephen Smalley
    National Security Agency



    \
     
     \ /
      Last update: 2009-05-12 14:55    [W:4.113 / U:0.284 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site