Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Tue, May 12, 2009 at 14:45, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:

> 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.

It will be its own filesystem type and no longer be auto-mounted in
initramfs at all. There is an option to request an auto-mount it for
the case the kernel mounted the rootfs. This is to allow the rescue
setup to work.

> 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).

How may that look like?

> 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?

It's a plain tmpfs, nothing different from a manual mounted one, just
that the kernel has created the instance and remembered the vfs mount
to put stuff into it, regardless of where is is mounted, or maybe not
mounted at all.

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