Date: Fri, 13 Feb 1998 16:18:58 -0800 From: Mike Smith <mike@smith.net.au> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Mike Smith <mike@smith.net.au>, Julian Elischer <julian@whistle.com>, Paul Traina <pst@juniper.net>, core@FreeBSD.ORG, junichi@jp.freebsd.org, committers@FreeBSD.ORG Subject: Re: wfd block major number reassignment from 24 to 1 Message-ID: <199802140018.QAA05385@dingo.cdrom.com> In-Reply-To: Your message of "Sat, 14 Feb 1998 00:51:26 %2B0100." <3896.887413886@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> In message <199802132343.PAA05222@dingo.cdrom.com>, Mike Smith writes: > > >Why? Do you do this for all the other files throughout your system > >that you change the permissions on? Do you *expect* permissions on > >arbitrary files to change when you reboot? > > Because devices come and go... No, they don't. The operating system comes and goes, but if I plug a device into my system, it *stays* there. If I take the OS away, and bring it back, the device is *still* there, and unless I explicitly do something to the device, I expect it to be like it was. > >> Yes I have, and no I do not accept that. > > > >But you do. Your entry in /etc/rc.local is an implementation of > >persistence. > > No it isn't, it's an implementation of policy. Er, you've already said that persistence is policy. I can't see any difference. > > - If you mount devfs somewhere else (think "chroot()"), the new > > permissions are not necessarily going to come across (cf. > > conversations with Julian on this). > > Which is the right thing to do, I may not even want all the devices > to come across... Sure. I agree entirely. > > - There is no logical connection between /etc/rc.local and /dev > > No, it should probably be called /etc/rc.deviceperms or something > along those lines. No again. It's specific to the mount instance. > > - If a device node first appears after /etc/rc.local is run, it is not > > possible to set its permissions. This is an issue for PCI, PnP, > > PCCARDs and CARDBUS at the very least. > > For each of these there will need to be some kind of daemon to manage > a whole lot of stuff anyway (ifconfig/mount &c &c), so it is clearly > a task for that daemon to get the perms right according to local > policy. No. Now you're suggesting that persistence should be implemented in multiple inconsistent fashions. > >> I belive persistence in devfs (as in /dev) is a very bad thing. > > > >You certainly haven't expressed that. In fact, everything else you > >have said in this message directly contradicts that. I can only > >conclude that you're reading a different meaning into "persistence" > >than I am, and by inference a lot of other people. > > What you want is: > > # ls -l /dev/asr33 > crw-rw-rw- 1 root wheel 0, 0 13 Feb 21:20 /dev/asr33 > # chown fumble /dev/asr33 > # ls -l /dev/asr33 > crw-rw-rw- 1 fumble wheel 0, 0 13 Feb 21:20 /dev/asr33 > # reboot > # ls -l /dev/asr33 > crw-rw-rw- 1 fumble wheel 0, 0 13 Feb 21:20 /dev/asr33 > > What I want is: > > # ls -l /dev/asr33 > crw-rw-rw- 1 root wheel 0, 0 13 Feb 21:20 /dev/asr33 > # chown fumble /dev/asr33 > # ls -l /dev/asr33 > crw-rw-rw- 1 fumble wheel 0, 0 13 Feb 21:20 /dev/asr33 > # reboot > # ls -l /dev/asr33 > crw-rw-rw- 1 root wheel 0, 0 13 Feb 21:20 /dev/asr33 > # vi /etc/rc.devperms > (add/change line to read: "chown asr* fumble.wheel" ) > # reboot > # ls -l /dev/asr33 > crw-rw-rw- 1 fumble wheel 0, 0 13 Feb 21:20 /dev/asr33 So we want the same thing. As I said, we are arguing implememtation. Count the lines, and the breaks in paradigm, between what you suggest I want and what you want. Your desire is for a more complicated, inconsistent, non-extensible technique. That's Bad. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802140018.QAA05385>