Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 May 2001 10:01:07 -0400 (EDT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc:        Greg Lehey <grog@lemis.com>, Eric Melville <eric@FreeBSD.org>, Kris Kennaway <kris@obsecurity.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: Destroying and remaking device nodes (was: cvs commit: src/sys/conf files options src/sys/alpha/conf GENERIC src/sys/i386/conf GENERIC NEWCARD NOTES src/sys/ia64/conf GENERIC src/sys/pc98/conf GENERIC src/sys/fs/devfs devfs_devs.c devfs_vfsops.c devfs_vnops.c) 
Message-ID:  <Pine.NEB.3.96L.1010514094858.70573E-100000@fledge.watson.org>
In-Reply-To: <20629.989848031@critter>

next in thread | previous in thread | raw e-mail | index | archive | help

On Mon, 14 May 2001, Poul-Henning Kamp wrote:

> In message <Pine.NEB.3.96L.1010514094148.70573D-100000@fledge.watson.org>, Robe
> rt Watson writes:
> 
> >Personally, I'd like to see rm unmodified: part of the goal here is to
> >allow /dev to act like a normal file system from the perspective of
> >management tools (including things like graphical file managers).
> >Modifying base system tools is going to hurt later.  We should really just
> >allow rm and rm -W to work as normal.  They use documented APIs as they
> >exist already.
> 
> I have had a number of people ask for "mknod" instead of "rm -W"  and
> after thinking about it I guess that is the most POLA compliant
> solution. 
> 
> I'll work that one tonight if I can. 

On the other hand, from the perspective of dynamically allocated device
major numbers for kernel modules, using whiteout *also* makes sense. :-) 
You can't mknod a device without a priori knowledge of its device numbers. 
As long as we like that assertion, I'm fine with us using mknod.

I recognize the jail issue as a problem, but think it would be fine for
the vop_whiteout code to simply do a:

if (jailed(p->p_ucred))
	return (EPERM);

> The mountflags issue persist in preventing the more powerfull
> specification of policy...

This is a continuing problem that I think Adrian Chadd agreed to fix, but
who hasn't been seen fixing anything much lately... :-)

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org      NAI Labs, Safeport Network Services




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?Pine.NEB.3.96L.1010514094858.70573E-100000>