Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Aug 2005 10:01:46 +0100
From:      Gavin Atkinson <gavin.atkinson@ury.york.ac.uk>
To:        Brian Fundakowski Feldman <green@freebsd.org>, Pawel Jakub Dawidek <pjd@freebsd.org>
Cc:        cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org
Subject:   Re: cvs commit: src/sys/geom/label g_label.c
Message-ID:  <1124182906.2492.4.camel@buffy.york.ac.uk>
In-Reply-To: <20050816081644.GA3944@garage.freebsd.pl>
References:  <200508120005.j7C05ARc090857@repoman.freebsd.org> <20050815053757.GB2660@green.homeunix.org> <20050815070033.GA8368@garage.freebsd.pl> <20050815125814.GC2660@green.homeunix.org> <20050816081644.GA3944@garage.freebsd.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2005-08-16 at 10:16 +0200, Pawel Jakub Dawidek wrote:
> On Mon, Aug 15, 2005 at 08:58:14AM -0400, Brian Fundakowski Feldman wrote:
> +> > +> Why would we want to prevent the usage of a specific directory structure
> +> > +> to represent GEOM's namespace, if that's what the administrator wants?
> +> > 
> +> > If the label name is 'foo/bar' it doesn't seems right to create 'foo'
> +> > directory and provider 'bar' inside. The label could be also '../random'
> +> > or something like this and I want to save administrator/user nasty surprises
> +> > when he inserts some random CD.
> +> 
> +> I like the idea of rejecting the latter, but what is the harm of the first
> +> case?  If I call something "foo/bar", I'll be surprised to find out that
> +> it's located at /dev/foo_bar... my preference would be for the name to be
> +> rejected completely instead of remapped, if a '/' is to not be allowed,
> +> but that's my own.
> 
> 	# cd /dev/foo
> 	# rm/anything bar
> 
> There was no label 'bar', right. Anyway. Instead of rejecting labels with
> '/' I can print a warning on the console that a bit different label will be
> used. What do you say?

FWIW, I would prefer to see this backed out, or at least not MFC'd.  I'm
using labels containing slashes as a way to split a large number of
devices up in /dev, and MFCing this would presumably break my setup.  As
far as I can tell, if somebody has used a "/" in a label, then that was
an administrative decision, and if possible we should obey that.

Is there any technical reason why a "/" cannot be allowed?  I do agree
that filtering out any occurances of "../" is a good idea.

Gavin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1124182906.2492.4.camel>