Date: Sat, 7 Sep 2013 20:26:11 GMT From: Charlie R <3zstbn24xn@snkmail.com> To: freebsd-gnats-submit@FreeBSD.org Subject: misc/181917: GELI: gshsec(8) doesn't autodetect or respect written metadata; has room for improvement on usage Message-ID: <201309072026.r87KQBsO056680@oldred.freebsd.org> Resent-Message-ID: <201309072030.r87KU02j085104@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 181917 >Category: misc >Synopsis: GELI: gshsec(8) doesn't autodetect or respect written metadata; has room for improvement on usage >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Sep 07 20:30:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Charlie R >Release: 9.2/amd64 >Organization: None >Environment: FreeBSD localhost 9.2-RC2 FreeBSD 9.2-RC2 #0 r254368: Thu Aug 15 18:49:04 UTC 2013 root@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 >Description: A "gshsec label" command writes metadata to two providers (confirmed by a gshsec dump right after), but there's no particular command to ask the kernel to try to look for providers which are a part of a gshsec set. So /dev/shsec/entry isn't populated automatically at times, although right after the "gshsec label" command it existed and works fine. But also because "gshsec label" seems destructive I would prefer that it would check for existing GEOM labels of any kind, requiring a "-f" to force overwrite. I had used it again thinking that it would detect a presence of an existing gshsec set and that the label command would trigger its appearance in /dev/shsec/. I'd like to see gshsec and others check for the presence of existing GEOM metadata, even of the same time, and to require -f to overwrite that. Also I'd like autodetection of a GEOM setup such as gshsec to be more comprehensive, or I'd like the user to specifically be able to manually request that this GEOM set be enabled (either through a gshsec command or some global GEOM command). >How-To-Repeat: Use gshsec label, stop and disconnect and remove one of the providers (suppose it is a .eli and one does geli detach). Notice how that upon reattach the gshsec label isn't automatically populated. Similarly note that there seems to be no way to resume an existing gshsec, even though there is actual metadata stored! Note that gshsec label will happily overwrite with a new label even if there is already existing data. >Fix: None >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201309072026.r87KQBsO056680>