Date: Mon, 3 Feb 2003 17:17:07 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Juli Mallett <jmallett@FreeBSD.org> Cc: Gordon Tetlow <gordont@gnf.org>, Dag-Erling Smorgrav <des@ofug.org>, phk@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/geom geom_vol_ffs.c Message-ID: <Pine.NEB.3.96L.1030203171621.80901S-100000@fledge.watson.org> In-Reply-To: <20030203134932.A44770@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Feb 2003, Juli Mallett wrote: > * De: Gordon Tetlow <gordont@gnf.org> [ Data: 2003-02-03 ] > [ Subjecte: Re: cvs commit: src/sys/geom geom_vol_ffs.c ] > > > - Although tunefs(8) won't let you set a volume label containing > > > anything but alphanumerics (IMHO, it should accept underscores as > > > well), there's nothing in g_vol_ffs_taste() that checks for invalid > > > characters in the label. What happens if I manually edit the > > > superblock and put a / in there? (imagine inserting a borrowed Zip > > > disk and boom...) > > > > I've got a commit in my tree that adds a comment about this. It's on > > my TODO list. I was thinking of adding . as a valid character as well > > (but disallowing leading periods for security reasons). > > Security reasons? What's wrong with things like ls hiding certain > volumes in /dev/vol/ if they aren't using -a or similar? Currently, there's a very small limit on the size of devfs device names. Poul-Henning has plans to increase that limit, meaning that a slightly deeper /dev is possible. It would also permit us to stick things like uuids in the devfs space. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories 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.1030203171621.80901S-100000>