Re: devfs: default permissions - SOLUTION

Richard Gooch (rgooch@atnf.CSIRO.AU)
Fri, 9 Jan 1998 17:56:07 +1100

Kevin Lentin writes:
> I have a proposal for solving almost all of the devfs permission problems.
> It's got a touch long but I'm trying to forsee the questions. Please read
> to the end if you're going to rip it apart :-)
>
> The main complaint we see is that the kernel may choose defaults that a
> sysadmin may not like. So I ask, how often does this happen? And the answer
> seems to be: once per installation. So I propose the following:
>
> - a .devperms file and a corresponding defdefperms file which work like
> .config and defconfig
> - a make devperms target which will allow you to edit .devperms (and
> a make menudevperms and xdevperms as well).
> - the file has the following format:
> # driver owner group mode
> hd 0 0 0600
> lp root lp 0660
>
> etc
> - During kernel compile, a script converts this into a suitable devperms.h
> file (just like the kernel compile turns .config into autoconf.h). That
> process would involve converting username and groupnames into numbers and
> creating a set of #defines.
>
> - So we end up with a devperms.h containing something like:
>
> /* hd 0 0 0600 */
> #define DEVPERM_hd_owner 0
> #define DEVPERM_hd_group 0
> #define DEVPERM_hd_mode 0600
>
> /* lp root lp 0660 */
> #define DEVPERM_lp_owner 0
> #define DEVPERM_lp_group 7
> #define DEVPERM_lp_mode 0660
>
> Now, each driver can #include <linux/devperm.h> or whatever and use those
> values when it creates devices. And it can be guaranteed that they will be
> there as long as appropriate entries are in defdevperms (which they should
> be - it becomes one of the things you do when you write a driver).

OK, one problem I see with this is that you have to maintain
permission info for each driver in defdevperms. A little bit of extra
work. It will be confusing to people who want to write their own
module and who don't know about defdevperms.

Another problem is that you'll want to copy over .devperms from one
kernel to the next, just like you copy .config around. You'll need to
make sure that the script *merges* .devperms and defdevperms together
into a new .devperms before generating devperm.h.

To make the configuration easier, you could generate .devperms from
the existing devices in /dev.

> The only remaining issue is modules...
>
> - It would be nice if insmod could change the defaults. That would allow
> people to configure slightly different machines that share a common
> kernel and set of modules. You put the changes in conf.modules instead of
> rc.d. The same way they might have to configure a different IRQ or
> different sound card or something between machines.
>
> - So I propose that devparm.h contain a few more #defines when modules are
> enabled. Something like this:
>
> #define MODULE_DEVPARM(_drv) \
> static int dev_owner = DEVPERM_##_drv##_owner; \
> MODULE_PARM(dev_owner, "i"); \
> static int dev_group = DEVPERM_##_drv##_group; \
> MODULE_PARM(dev_group, "i"); \
> static int dev_mode = DEVPERM_##_drv##_mode; \
> MODULE_PARM(dev_mode, "i")

Erk! Getting complicated.

> So what do people think? I argue that it is as much effort as setting up an
> initial /dev and should almost entirely remove the need for storing /dev
> and restoring it at reboot. AND it removes the thing I don't like which
> is the need to set up devices at boot time, thus creating entries in a
> virtual filesystem that is supposed to do it for you.

I personally think that doing:
# chmod go= /dev/lp0

is really easy and obvious. And the saving script can be as simple as
using find and tar together. The restoring script only needs to call
tar. Ensuring persistence is really easy.

Regards,

Richard....