From owner-cvs-all Fri Feb 13 16:05:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA11008 for cvs-all-outgoing; Fri, 13 Feb 1998 16:05:22 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA10271; Fri, 13 Feb 1998 16:02:32 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.5) with ESMTP id AAA03898; Sat, 14 Feb 1998 00:51:27 +0100 (CET) To: Mike Smith cc: Julian Elischer , Paul Traina , core@FreeBSD.ORG, junichi@jp.freebsd.org, committers@FreeBSD.ORG Subject: Re: wfd block major number reassignment from 24 to 1 In-reply-to: Your message of "Fri, 13 Feb 1998 15:43:16 PST." <199802132343.PAA05222@dingo.cdrom.com> Date: Sat, 14 Feb 1998 00:51:26 +0100 Message-ID: <3896.887413886@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk 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