Re: scanning sysfs to populate /dev

From: Ryan Reich (ryanr_at_uchicago.edu)
Date: 04/26/05

  • Next message: phil-news-nospam_at_ipal.net: "Re: kernel boot parameters -> init environment" 
    Date: Tue, 26 Apr 2005 18:20:03 GMT

    phil-news-nospam@ipal.net wrote:
    > On Tue, 26 Apr 2005 14:07:38 GMT Ryan Reich <ryanr@uchicago.edu> wrote: | My
    > thoughts on this are that the early userspace philosophy is not to set up a |
    > perfect system before init even runs, but simply to arrange for the rc system
    > to | see a functional environment that it can then put the finishing touches
    > on. I | can see it being worthwhile for your utility to do some heuristics
    > and figure | out which device / is on, or load some drivers and start up LVM
    > or RAID if | necessary, or some such thing that the kernel developers
    > wouldn't want to put | into their startup code, but once you have the ability
    > to actually mount your | filesystems why would you need to do anything more
    > from early userspace when you | would have the infinite capacity for
    > configuration available from data on disk?
    >
    > There will definitely need to be 2 levels of configuration going on, the
    > first of which is not as easy to change, and thus needs to as general as
    > possible. But I'm also trying to make it as correct as possible. Any
    > devices that always need a particular permission mode, should get that here
    > so the functionality is as complete as it possibly can be by the time the
    > regular init/rc systemstarts. The reason I want to do that is because the
    > traditional init/rc code would see the disk filesystem based device nodes in
    > the ordinary case. But for this setup, I want to approximate that as much as
    > possible so that a minimum of change is needed to the init/rc stuff.
    >
    > Traditionally, the kernel only deals with devices by their device code.
    > Having a device namespace in the kernel, is a departure from that philosophy.
    > The first appearance is the ability of the kernel to recognize root=/dev/hda1
    > in place of root=301. The next appearance was the whole devfs design. That
    > had its problems so now we have sysfs. Actually, network interfaces are a
    > namespace that appeared even before any of this. I'm not opposed to the
    > kernel knowing namespace, as that can be an easy way to deal with the huge
    > device space that looms. But consider that namespace was previously an
    > external (of the kernel) policy, and now it is migrating to device drivers.
    > Shouldn't common metadata have gone along with it (not all of it, just what
    > is considered essential enough to be universally the same). Basically, what
    > I want to find is that essential universal metadata policy. Then the rc
    > scripts can tweak it from there.

    So what I'm saying is that I don't think there is an essential universal
    metadata policy. Just looking at what udev does, if you don't bother to specify
    permissions for any nodes it just creates them with the default permissions
    which you put in /etc/udev/udev.conf, and there are apparently no worries about
    this. Anyway, if you want to make the initramfs code as generic as possible you
    don't WANT to specify permissions, since that would enforce a policy on a system
    you don't know a priori to have any particular policy. Unless this is just for
    your own, personal computer, of course. From what I've seen the permissions of
    a device node are largely irrelevant to its functionality except as perceived by
    the person trying to use it: that is, the driver doesn't worry over which group
    owns the node, or what permissions some other user has on the node. It can't,
    since there can be multiple nodes pointing at the same driver (i.e. with the
    same major/minor numbers) and then what is the driver to think? Is there a case
    anywhere in a Unix system where the permissions on a file affect anything other
    than a user's ability to read, write to, or execute that file? My solution
    remains that you give all nodes 777 (or 666, since no one executes device nodes)
    permissions owned by root:root, and if you feel like customizing, add an init
    script. I think one new script is a pretty minimal change considering that you
    are completely reconceiving the system's namespace. 

    -- 
Ryan Reich
ryanr@uchicago.edu
  • Next message: phil-news-nospam_at_ipal.net: "Re: kernel boot parameters -> init environment"

    Relevant Pages

    • Re: [RFC][PATCH] Privilege dropping security module
      ... dpriv.c contains the struct security_operations hooks for dpriv. ... You're masking file permissions. ... And stick with your namespace, ... * Parse policy lines one at a time. ...
      (Linux-Kernel)
    • [PATCH 4/4] SELinux: validate kernel object classes and permissions
      ... This is a new object class and permission validation scheme that validates ... against the defined kernel headers. ... and permissions that do not conflict with the kernel definitions to be ... This validation is now done for all policy loads, ...
      (Linux-Kernel)
    • Re: setroub;eshoot problem
      ... Unknown Permissions Handling ... # kernel but missing from the policy. ...
      (Fedora)
    • [RFC][PATCH] Privilege dropping security module
      ... dpriv.c contains the struct security_operations hooks for dpriv. ... * under the terms of the GNU General Public License as published by the Free ... * Parse policy lines one at a time. ... * Open file descriptors and their implied permissions based on @policy ...
      (Linux-Kernel)
    • Re: whats next for the linux kernel?
      ... `ls -l' can show you the complete permissions of a lot of files in a few ... permission and some of the inheritees' permissions might suddenly make ... including UTF-8 canoncalization code, inside the kernel. ... complex and thus, when they *do* fail, the failures are correspondingly ...
      (Linux-Kernel)