From owner-freebsd-multimedia@FreeBSD.ORG Sat Jan 7 18:37:59 2006 Return-Path: X-Original-To: freebsd-multimedia@freebsd.org Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C891A16A41F for ; Sat, 7 Jan 2006 18:37:59 +0000 (GMT) (envelope-from SRS0=zaS+=3D=FreeBSD.org=se@srs.kundenserver.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0728A43D46 for ; Sat, 7 Jan 2006 18:37:58 +0000 (GMT) (envelope-from SRS0=zaS+=3D=FreeBSD.org=se@srs.kundenserver.de) Received: from [80.135.135.52] (helo=Gatekeeper.FreeBSD.org) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1EvIwp2Bpz-00053X; Sat, 07 Jan 2006 19:37:51 +0100 Received: from StefanEsser.FreeBSD.org (se [192.168.0.10]) by Gatekeeper.FreeBSD.org (Postfix) with ESMTP id 7C116B814; Sat, 7 Jan 2006 19:37:50 +0100 (CET) Received: by StefanEsser.FreeBSD.org (Postfix, from userid 200) id AF3252301; Sat, 7 Jan 2006 19:37:49 +0100 (CET) Date: Sat, 7 Jan 2006 19:37:49 +0100 From: Stefan =?iso-8859-1?Q?E=DFer?= To: Arne Woerner Message-ID: <20060107183749.GA83273@StefanEsser.FreeBSD.org> Mail-Followup-To: Stefan =?iso-8859-1?Q?E=DFer?= , Arne Woerner , Sandor Z Nemeth , freebsd-multimedia@freebsd.org References: <20060107161111.GA42739@StefanEsser.FreeBSD.org> <20060107163643.12201.qmail@web30310.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20060107163643.12201.qmail@web30310.mail.mud.yahoo.com> User-Agent: Mutt/1.5.11 X-Provags-ID: kundenserver.de abuse@kundenserver.de login:fa3fae9b6ca38d745862a668565919f6 Cc: freebsd-multimedia@freebsd.org Subject: Re: xsane as user X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2006 18:38:00 -0000 On 2006-01-07 08:36 -0800, Arne Woerner wrote: > --- Stefan Eßer wrote: > > > % cat /etc/devfs.conf > > > perm uscanner0 0664 > > > > Hmmm, why 0664? > > > Oh... I put myself into the operator group... Yes, that's what I propose, too. Then 0660 is sufficient. > I saw that too late... I hope my example still clear enough... It > should have been 0666 there too. That allows any user (i.e. any process on the system) to access the scanner and thus documents on it. Depends on the confidentiality of those documents whether that's acceptable ;-) > > Interesting idea to apply devfs rules from > > devd ... > > > I did not know, what devfs is good for, so I put it into devd so > that it makes sense in my setting (when I unplugged the scanner > the devfs settings were lost after I re-plugged the scanner). > > > attach 100 { > > device-name "uscanner[0-9]+"; > > action "chmod 660 /dev/$device-name"; > > }; > > > This creates uncontrolled redundancy, because then I have the > perms set in devfs.conf and in devd.conf... Correct. These two files serve different purposes, but there has been some discussion about this topic recently. As of now, devfs.conf is used to specify the initial state of the device nodes created in /dev. When there was a /dev on the root file system, ownership and permissions were persistent, and you could have alias names for devices by creating symbolic links in /dev. To reconstruct a sane initial state (if the compiled in default permissions are in the kernel are not considered appropriate), the commands in devfs.conf are executed when going multi-user (via /etc/rc.d/devfs). > I haven't understood the devfs/devd idea completely... :-) The devd process waits for changes in the device setup (e.g. when a removable device is attached or detached) and executes the commands specific to that device in devd.conf. If the scanner is connected to a running system, there will be a new uscanner device node (e.g. /dev/uscanner0), and devd can not only set the permissions but could execute any arbitrary command with sensible parameters (e.g. the device name can be passed). Executing /etc/rc.d/devfs from within devd is possible, but may have side effects (the initial settings are applied to all devices, though some may have been modified in between and should not beb reset). Besides, running this startup script is more effort than just calling chmod with the device node as a parameter. For that reason, the devd.conf line I sent in my previous mail does just what's needed (adjusts the permissions) without the danger of side effects on other devices and I'd suggest to switch over to using it ;-) Regards, STefan