From edwin@mavetju.org  Mon Mar  8 17:23:21 2004
Return-Path: <edwin@mavetju.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 0CE9116A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Mon,  8 Mar 2004 17:23:21 -0800 (PST)
Received: from mailout2.barnet.com.au (mailout2.barnet.com.au [218.185.88.16])
	by mx1.FreeBSD.org (Postfix) with ESMTP id CEB6A43D39
	for <FreeBSD-gnats-submit@freebsd.org>; Mon,  8 Mar 2004 17:23:19 -0800 (PST)
	(envelope-from edwin@mavetju.org)
Received: by mailout2.barnet.com.au (Postfix, from userid 27)
	id D1DCCAA625B; Tue,  9 Mar 2004 12:23:16 +1100 (EST)
Received: from mail2-auth.barnet.com.au (localhost [127.0.0.1])
	by mail2.barnet.com.au (Postfix) with ESMTP id 074F0B29F9F
	for <FreeBSD-gnats-submit@freebsd.org>; Tue,  9 Mar 2004 12:23:15 +1100 (EST)
Received: from k7.mavetju (edwin.adsl.barnet.com.au [203.111.122.2])
	by mail2-auth.barnet.com.au (Postfix) with ESMTP id 9359E1937C
	for <FreeBSD-gnats-submit@freebsd.org>; Tue,  9 Mar 2004 12:23:15 +1100 (EST)
Received: by k7.mavetju (Postfix, from userid 1001)
	id 38313618F; Tue,  9 Mar 2004 12:23:15 +1100 (EST)
Message-Id: <20040309012315.38313618F@k7.mavetju>
Date: Tue,  9 Mar 2004 12:23:15 +1100 (EST)
From: Edwin Groothuis <edwin@mavetju.org>
Reply-To: Edwin Groothuis <edwin@mavetju.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: devfs looses permissions
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         63954
>Category:       kern
>Synopsis:       devfs loses permissions
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-rc
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Mar 08 17:30:17 PST 2004
>Closed-Date:    Thu Jun 30 09:20:03 GMT 2005
>Last-Modified:  Mon Jul  4 09:00:32 GMT 2005
>Originator:     Edwin Groothuis
>Release:        FreeBSD 5.2.1-RELEASE i386
>Organization:
-
>Environment:
System: FreeBSD k7.mavetju 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #3: Fri Feb 27 13:54:29 EST 2004 edwin@k7.mavetju:/usr/src/sys/i386/compile/k7 i386

>Description:

I have this in /etc/devfs.conf:
	perm    bpf0    640
	perm    bpf1    640
	perm    bpf2    640
	perm    bpf3    640

Running "/etc/rc.d/devfs start" will create the devices:
	[~] edwin@k7>ls -al /dev/bpf*
	crw-r-----  1 root  wheel   23,   0 Mar  8 16:46 /dev/bpf0
	crw-r-----  1 root  wheel   23,   1 Feb 27 15:09 /dev/bpf1
	crw-r-----  1 root  wheel   23,   2 Feb 27 16:46 /dev/bpf3
	crw-r-----  1 root  wheel   23,   3 Feb 27 16:46 /dev/bpf3

Only to see the next morning:
	[~] edwin@k7>ls -al /dev/bpf*
	crw-r-----  1 root  wheel   23,   0 Mar  8 16:46 /dev/bpf0
	crw-r-----  1 root  wheel   23,   1 Feb 27 15:09 /dev/bpf1

	(bpf1 is constantly opened by trafshow)

"devfs rule showsets" and "devfs rule show" don't return any
information.

>How-To-Repeat:

as above

>Fix:

Any suggestions?
>Release-Note:
>Audit-Trail:

From: Colin Percival <colin.percival@wadham.ox.ac.uk>
To: freebsd-gnats-submit@FreeBSD.org, edwin@mavetju.org
Cc:  
Subject: Re: kern/63954: devfs looses permissions
Date: Wed, 10 Mar 2004 04:35:25 +0000

    Maybe I'm missing something, but I can't see any
 permissions being lost.  I see device nodes being
 removed, but that's all.
    What happens if you start a few tcpdump processes
 and the nodes are recreated?
 
 Colin Percival
 

From: Edwin Groothuis <edwin@mavetju.org>
To: freebsd-gnats-submit@FreeBSD.org
Cc: Colin Percival <colin.percival@wadham.ox.ac.uk>
Subject: Re: kern/63954: devfs looses permissions
Date: Wed, 10 Mar 2004 15:53:50 +1100

 On Tue, Mar 09, 2004 at 08:40:11PM -0800, Colin Percival wrote:
 >     Maybe I'm missing something, but I can't see any
 >  permissions being lost.  I see device nodes being
 >  removed, but that's all.
 
 Yes they are removed. That's part of the problem, because when
 they're (tried to be) opened again, I get a permission denied.
 
 >     What happens if you start a few tcpdump processes
 >  and the nodes are recreated?
 
 [~] edwin@k7>ls -al /dev/bpf*
 crw-r-----  1 root  wheel   23,   0 Mar  8 16:46 /dev/bpf0
 crw-r-----  1 root  wheel   23,   1 Feb 27 15:09 /dev/bpf1
 
 [~] edwin@k7>groups
 edwin wheel
 
 [~] edwin@k7>tcpdump -ni fxp0
 tcpdump: (no devices found) /dev/bpf2: Permission denied
 
 Edwin
 -- 
 Edwin Groothuis      |            Personal website: http://www.mavetju.org
 edwin@mavetju.org    |          Weblog: http://weblog.barnet.com.au/edwin/

From: Marco Molteni <mmolteni@cisco.com>
To: freebsd-gnats-submit@freebsd.org
Cc: edwin@mavetju.org, colin.percival@wadham.ox.ac.uk
Subject: Re: kern/63954: devfs looses permissions
Date: Mon, 19 Apr 2004 12:23:33 +0200

 Hi all,
 
 any news on this?
 I agree with Edwin's analysis and I am having the same problem.
 
 What does all the people using -current do ? Su to root just to run
 tcpdump/ethereal (and so open themselves to attacks via crafted packets) ?
 I am missing something.
 
 -- 
 marco
State-Changed-From-To: open->analyzed 
State-Changed-By: phk 
State-Changed-When: Thu Jun 17 06:35:48 GMT 2004 
State-Changed-Why:  
The problem here is that /etc/devfs.conf does not in fact work 
as it should.  It just blindly applies the changes to the current 
contents of /dev where it should in fact create devfs rules and 
engange and apply those. 

This is really a task for our RCng crew, but I am not sure if 
rc@ is a valid PR owner address. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=63954 
Responsible-Changed-From-To: freebsd-bugs->freebsd-rc 
Responsible-Changed-By: arved 
Responsible-Changed-When: Mon Aug 30 16:22:20 GMT 2004 
Responsible-Changed-Why:  
phk thinks this problem can be resolved by RCng. Over to mailinglist for 
review. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=63954 

From: Marco Molteni <mmolteni@cisco.com>
To: freebsd-gnats-submit@FreeBSD.org, freebsd-rc@FreeBSD.org,
	phk@FreeBSD.org
Cc: edwin@mavetju.org, arved@FreeBSD.org
Subject: Re: kern/63954: devfs loses permissions
Date: Thu, 25 Nov 2004 09:48:45 +0100

 Hi all,
 
 any news on this?
 
 thanks
 marco

From: Matteo Riondato <rionda@gufi.org>
To: bug-followup@FreeBSD.org, edwin@mavetju.org, mmolteni@cisco.com,
	freebsd-rc@freebsd.org
Cc:  
Subject: Re: kern/63954: devfs loses permissions
Date: Wed, 15 Jun 2005 18:27:44 +0200

 Patch for this against /etc/rc.d/devfs follows and can be found at
 http://www.riondabsd.net/diff/devfs.diff. Please note that this patch
 includes fix for PR bin/65693 (wildcarded device names in devfs.conf
 ). I hope someone will pick this up and commit the patch.
 
 --- devfs.old	Wed Jun  8 22:50:32 2005
 +++ devfs	Wed Jun 15 14:50:37 2005
 @@ -37,25 +37,44 @@
  	read_devfs_conf
  }
  
 +
 +do_action()
 +{
 +	case "$1" in
 +	l*)	if [ -c $2 -a ! -e $3 ]; then
 +			ln -fs $2 $3
 +		fi
 +		;;
 +	o*)	if [ -c $2 ]; then
 +			chown $3 $2
 +		fi
 +		if echo $3 | grep -q : ; then
 +			uid=${3%%:*}
 +			gid=${3##*:}
 +			devfs rule add path $2 user $uid group $gid
 +			devfs rule apply path $2 user $uid group $gid
 +		else
 +			devfs rule add path $2 user $3
 +			devfs rule apply path $2 user $3
 +		fi	
 +		;;
 +	p*)	if [ -c $2 ]; then
 +			chmod $3 $2
 +		fi	
 +			devfs rule add path $2 mode $3
 +			devfs rule apply path $2 
 +		;;
 +	esac
 +}	
 +
  read_devfs_conf()
  {
  	if [ -r /etc/devfs.conf ]; then
  		cd /dev
  		while read action device parameter; do
 -			case "${action}" in
 -			l*)	if [ -c ${device} -a ! -e ${parameter} ]; then
 -					ln -fs ${device} ${parameter}
 -				fi
 -				;;
 -			o*)	if [ -c ${device} ]; then
 -					chown ${parameter} ${device}
 -				fi
 -				;;
 -			p*)	if [ -c ${device} ]; then
 -					chmod ${parameter} ${device}
 -				fi
 -				;;
 -			esac
 +			for dev_name in ${device}; do
 +				do_action ${action} ${dev_name} ${parameter} 
 +			done	
  		done < /etc/devfs.conf
  	fi
  }
 
 Best Regards
 -- 
 Rionda aka Matteo Riondato
 G.U.F.I. Staff Member (http://www.gufi.org)
 FreeSBIE Developer (http://www.freesbie.org)

From: Matteo Riondato <matteo@freebsd.org>
To: Mike Makonnen <mtm@identd.net>
Cc: bug-followup@FreeBSD.org, edwin@mavetju.org, mmolteni@cisco.com,
	freebsd-rc@freebsd.org
Subject: Re: kern/63954: devfs loses permissions
Date: Wed, 29 Jun 2005 18:45:50 +0200

 On Wed, Jun 29, 2005 at 07:13:19PM +0300, Mike Makonnen wrote:
 > On Wed, Jun 15, 2005 at 06:27:44PM +0200, Matteo Riondato wrote:
 > > Patch for this against /etc/rc.d/devfs follows and can be found at
 > > http://www.riondabsd.net/diff/devfs.diff. Please note that this patch
 > > includes fix for PR bin/65693 (wildcarded device names in devfs.conf
 > > ). I hope someone will pick this up and commit the patch.
 > > 
 > 
 > ummm... you have the right idea, except it has already been implemented for
 > a while: devfs.rules(5). The devfs.conf(5) file is
 > still with us because it does one thing devfs.rules(5) can't do, which is
 > make symlinks (which it can't because devfs(8) can't :-))
 > 
 > So, what you should do is edit /etc/devfs.rules with:
 > [myworkstation=500]
 > add path bpf* mode 0640
 > 
 > Then edit /etc/rc.conf and add:
 > devfs_system_ruleset=myworkstation
 
 Then having any other kind of rule in devfs.conf should is kind of
 useless, at least for devices that can "disappear", since rules
 referring to them will not be added do the devfs ruleset, and this
 implies that one have to rerun /etc/rc.d/devfs after reinserting the
 pcmcia nic or after launching tcpdump or whatever.  
 Anyway, I see that this is documented on devfs.conf(5), so you can
 close this PR (and bin/65693 too).
 -- 
 Matteo Riondato
 FreeBSD Volunteer (http://freebsd.org)
 G.U.F.I. Staff Member (http://www.gufi.org)
 FreeSBIE Developer (http://www.freesbie.org)
State-Changed-From-To: analyzed->closed 
State-Changed-By: mtm 
State-Changed-When: Thu Jun 30 09:18:01 GMT 2005 
State-Changed-Why:  
devfs.conf(5) has been superceeded by devfs.rules(5). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=63954 

From: Marco Molteni <mmolteni@cisco.com>
To: Mike Makonnen <mtm@identd.net>
Cc: Matteo Riondato <matteo@freebsd.org>, bug-followup@freebsd.org,
        edwin@mavetju.org, freebsd-rc@freebsd.org
Subject: Re: kern/63954: devfs loses permissions
Date: Thu, 30 Jun 2005 15:13:54 +0200

 On Thursday 30 June 2005 11:08, Mike Makonnen wrote:
 > On Wed, Jun 29, 2005 at 06:45:50PM +0200, Matteo Riondato wrote:
 > > Then having any other kind of rule in devfs.conf should is kind of
 > > useless, at least for devices that can "disappear", since rules
 > > referring to them will not be added do the devfs ruleset, and this
 > > implies that one have to rerun /etc/rc.d/devfs after reinserting
 > > the pcmcia nic or after launching tcpdump or whatever.
 >
 > Just to make it clear: devfs.rules is the correct way to do what you
 > and the original poster wants. Once the rules have been applied it
 > doesn't matter if the device is or isn't in /dev, whether you remove
 > it or plug it in later. Once you run rc.d/devfs you don't have to
 > rerun it again unless you add/change/remove the rules.
 
 Mike,
 
 Matteo was referring to devfs.conf, not devfs.rules.
 
 devfs.conf should die, it is there to confuse people.
 
 marco

From: Marco Molteni <mmolteni@cisco.com>
To: Mike Makonnen <mtm@identd.net>
Cc: Matteo Riondato <matteo@freebsd.org>, bug-followup@freebsd.org,
        edwin@mavetju.org, freebsd-rc@freebsd.org
Subject: Re: kern/63954: devfs loses permissions
Date: Mon, 4 Jul 2005 10:58:27 +0200

 On Friday 01 July 2005 12:05, Mike Makonnen wrote:
 
 > On Thu, Jun 30, 2005 at 03:13:54PM +0200, Marco Molteni wrote:
 > > Mike,
 > >
 > > Matteo was referring to devfs.conf, not devfs.rules.
 >
 > ahh ok.
 >
 > > devfs.conf should die, it is there to confuse people.
 >
 > I had thought about removing it, but it still does one thing
 > devfs.rules can't do, namely symlinking. For devfs.rules to do
 > symlinking devfs(8) needs to support it. I've been meaning to take a
 > look at that for a while but keep putting it off.
 
 I'd be very grateful if you founded the time to look at it, it would be 
 a much needed clean-up IMHO.
 
 thanks again
 marco
>Unformatted:
