Date: Sat, 14 Feb 1998 00:51:26 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Mike Smith <mike@smith.net.au> Cc: 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: <3896.887413886@critter.freebsd.dk> In-Reply-To: Your message of "Fri, 13 Feb 1998 15:43:16 PST." <199802132343.PAA05222@dingo.cdrom.com>
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... >> 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. > - 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... > - 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. > - 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. >> 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 -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "Drink MONO-tonic, it goes down but it will NEVER come back up!" 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?3896.887413886>