From owner-freebsd-hackers@freebsd.org Wed Mar 30 21:03:28 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C518AE3A46 for ; Wed, 30 Mar 2016 21:03:28 +0000 (UTC) (envelope-from vbatts@gmail.com) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 440B3176C for ; Wed, 30 Mar 2016 21:03:28 +0000 (UTC) (envelope-from vbatts@gmail.com) Received: by mail-ob0-x235.google.com with SMTP id fp4so8468762obb.2 for ; Wed, 30 Mar 2016 14:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to; bh=b3iGBa4+WgKUFdJpat3W0crCK2Za/Y8sJDcvvFd8HZE=; b=kJ5triuuaUZkgPC4qe1bqiv0DV8gUHDrmfCGngzHv1pMh3zu4VORH6yalZ+OBqZFFX r1e6KmLn8zbCyBg8h2zFdFXv1lThcnYQbQX1WJvCMQgOdfZQquBu7vL4WlLiVWGKQIVc +/m4bbGuZjwWPIgSBUNK3UtfSYV+VXOlNDKwwcOIrfCymW/s54dGQjYEwB25Kk08zccC Z/ePtakD2AHxEtVLaf/2JqrWhJCTx3MaHOHU1SuVd57QtplwTEr/kcBjl3Z6K1LZM9ip Mjf2AIPIgTpHi7mTdMDJTF7OPLMneQfK3tiEqScF/op3CIm5H9Swxpxe6iv4Ym9ZOsGK HxEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to; bh=b3iGBa4+WgKUFdJpat3W0crCK2Za/Y8sJDcvvFd8HZE=; b=LEaFp4a4AoKMcQUJQClg8vTjCbTAeAqItp5xy22k/ttnfCWNxmydIoywpzO9zEos3C a3ZP8u8ULZzaZYeQpSzqXjxmVVj46yMpoYz61U6PM7d1pEW/UdnZH8gO27hgEjFRfOw8 itZQb10EZlWarzERQ5iIC5uVxO/pk03xeY007A+O7Vp45McI/LxIeM1JVHq4MEuBj+Gp KKF+cO+DR+rPkVdyVMezPIQ2aooUBoV1iV/AjsNOgDVEF2QU4QrpIO8CbeW3u2fdAqAB 1PWJ26wnUnboIFOFNmgdzu1X7oxFo3rkMxd8HNONflhE22pUo6Srw3GXTxL+5EO7NG7e +TqQ== X-Gm-Message-State: AD7BkJLgxICEBv0BQ59D0uySb3rGb5Rpv2gl69dLGAoY8kNb0MEvJPx3R7hE4JJoPWdDz2RN6PjufSxTkUbmcg== MIME-Version: 1.0 X-Received: by 10.60.176.100 with SMTP id ch4mr6381826oec.7.1459371807553; Wed, 30 Mar 2016 14:03:27 -0700 (PDT) Sender: vbatts@gmail.com Received: by 10.182.109.228 with HTTP; Wed, 30 Mar 2016 14:03:27 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Mar 2016 17:03:27 -0400 X-Google-Sender-Auth: i8xrGD8rlB6FUQJbvDZOzkDw7-I Message-ID: Subject: Re: [RFE] mtree support for extattr? From: Vincent Batts To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 21:03:28 -0000 On Wed, Mar 9, 2016 at 10:17 AM, Vincent Batts wrote: > Hello all, > > This is a first post from me. The `mtree` utility (./contrib/mtree/) > and the specs that it produces and validates has found it's way into > projects that I am involved in. While the projects are initially very > Linux focused, they are not limited to such. There is an mtree-port > that has been started for Linux, but is not widely packaged yet. Also, > libarchive has support for parsing and creating mtree specs. > > On most Linux filesystems, extend attributes are used commonly for > storing ACLs, capabilities, etc. These attributes are something that > most definitely would be interesting keywords to include in the spec > of a directory hierarchy. > From my researching, it seems that extattr support for mtree on > freebsd is not present, while the sys/extattr.h and UFS could support > it. > > It seems this is a valuable feature to add and would be widely useful. > Some of the mechanics would be interesting to handle the collation of > the extattr data into the keywords for files in the mtree spec. As the > key/values are namespaced, perhaps the mtree keyword would use the > namespace.key and prefix it with 'extattr.' or 'xattr' or similar. > Such that the entry in the mtree spec looks like > ``` > my.file \ > mode=0644 size=24542 time=1455996582.000000000 \ > extattr.system.mykey=myvalue \ > > sha512digest=f758e6d04b527cc024aa70ffaaa75b4899429498d246f41a057753dc51b7d49e0f6b512c1f1920435585067209863c529b2038101ce0576138c7eee7ca359b7c > ``` > Some issues that I have with this is the information leak of the > values of the extended attributes. Also, on Linux xattrs are expected > to be ascii strings, it is not uncommon to find binary content in the > value. > For these two cases, it seems nicer to just include a checksum of the > value of each extended attribute. This then requires an election to > which hash to use for the checksum digest. > > I look forward to your response and next steps! Hello all, In update, I have recently opened the project "go-mtree" ( https://github.com/vbatts/go-mtree ). It is a go programming language library for interacting with the mtree specification. It has a simple cli, which is largely for testing and not intended to replace the `mtree` executable. I did include the xattr support as I mentioned. It's design ought to be consistent with how FreeBSD extattr work. It would be great to here from anyone on extended attribute support making its way into the FreeBSD mtree and specification. Thoughts? vb