From owner-freebsd-bugs@FreeBSD.ORG Sat Sep 7 20:30:00 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8D978813 for ; Sat, 7 Sep 2013 20:30:00 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6DFA323CD for ; Sat, 7 Sep 2013 20:30:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r87KU0qQ085147 for ; Sat, 7 Sep 2013 20:30:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r87KU02j085104; Sat, 7 Sep 2013 20:30:00 GMT (envelope-from gnats) Resent-Date: Sat, 7 Sep 2013 20:30:00 GMT Resent-Message-Id: <201309072030.r87KU02j085104@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Charlie R <3zstbn24xn@snkmail.com> Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 240E36B6 for ; Sat, 7 Sep 2013 20:26:12 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from oldred.freebsd.org (oldred.freebsd.org [8.8.178.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1014223B6 for ; Sat, 7 Sep 2013 20:26:12 +0000 (UTC) Received: from oldred.freebsd.org ([127.0.1.6]) by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id r87KQBcE056683 for ; Sat, 7 Sep 2013 20:26:11 GMT (envelope-from nobody@oldred.freebsd.org) Received: (from nobody@localhost) by oldred.freebsd.org (8.14.5/8.14.5/Submit) id r87KQBsO056680; Sat, 7 Sep 2013 20:26:11 GMT (envelope-from nobody) Message-Id: <201309072026.r87KQBsO056680@oldred.freebsd.org> Date: Sat, 7 Sep 2013 20:26:11 GMT From: Charlie R <3zstbn24xn@snkmail.com> To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: misc/181917: GELI: gshsec(8) doesn't autodetect or respect written metadata; has room for improvement on usage X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 20:30:00 -0000 >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: