From owner-freebsd-questions@FreeBSD.ORG Thu May 29 13:09:14 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15667C8C for ; Thu, 29 May 2014 13:09:14 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A123F27C2 for ; Thu, 29 May 2014 13:09:13 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id a1so362719wgh.15 for ; Thu, 29 May 2014 06:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4cd+Qso/E34d/XpmyWY/zh0Qr+nDeiBCoeCj6l6UcHI=; b=mInTHe2YjaO2SWpOMAgE4sPf5WZSkN58hTG3MEoKS3OMmwUXgzVuD4j0qivtezeAxt hhYjFgBS7WiKSy9m4YoPD5O4DDKVqkEMbE26+nJ+MrT5M1FuFPDfk+NIu931upl/d9SR oJxFEpwcKoMsM0HCjdk0foxhcWeJHNcJdIkJJWq4f6soMk3Zf6eaHqfczuPkCere6ggo oOCJLjasjFlhy6nOzmCzd1dNkBRgZgLY/BqMT4ay8tyOEs1IAKBvDaTE6p/f+asdDgOa GyvmrnwK4mQghw6yuVVb2zxWedz5s3BVkTuR7yZzgcrKDnvFFYTfiKeCtrbuqSGS6r72 7LzA== X-Received: by 10.194.79.36 with SMTP id g4mr10056576wjx.71.1401368951899; Thu, 29 May 2014 06:09:11 -0700 (PDT) Received: from guillercussimac.home (95-91-242-223-dynip.superkabel.de. [95.91.242.223]) by mx.google.com with ESMTPSA id ed6sm25620194wib.20.2014.05.29.06.09.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 06:09:11 -0700 (PDT) Subject: Re: Mounting a ZFS snapshot by another user Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=iso-8859-1 From: Guillermo Marcus In-Reply-To: <5387154F.5040502@cyberleo.net> Date: Thu, 29 May 2014 15:09:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <843804C5-2D6E-4E7C-B2DF-858BD2E8B8AA@gmail.com> References: <80D52646-2377-447F-BBC4-BEF642585391@gmail.com> <5387154F.5040502@cyberleo.net> To: CyberLeo Kitsana X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-questions@FreeBSD.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:09:14 -0000 On 29 May 2014, at 13:09, CyberLeo Kitsana = wrote: > On 05/28/2014 03:17 PM, Guillermo Marcus wrote: >> Hi all, >>=20 >> I am using ZFS in a FreeBSD 10.0-RELEASE (10.0-RELEASE FreeBSD = 10.0-RELEASE #0 r260789). I setup some scripts to create snapshots of my = ZFS pool at regular intervals, and then another script to mount the = latest snapshot of each dataset in the pool to a specific location, = recreating a snapshot of my pool for backup. The goal is to use Bacula = to always backup the snapshot, to avoid data being in an inconsistent = state. The mount script is then executed by the bacula user at the = beginning of the backup job. The scripts work fine, but I have an issue = with the script being executed by the backup user and not the pool = owner. >=20 > >=20 >> Here is the thing: it works only partially. Apparently, it requires = that the mount point of the dataset be owned by the bacula user and not = dataowner, even when the user bacula has full access. Example: >=20 > >=20 >> Can anyone explain what I am missing? >=20 > If I remember correctly, one of the security consolations inherent in > vfs.usermount is that the user have sufficient access to both the = source > node and the target directory; to prevent, say, a mortal user mounting > something over /bin or whatever. >=20 then this is hinting at a bug. The user has access to both the source = and the target over ACLs, but is not respecting it. > You may get a more consistent behaviour if you abstract the snapshot > manipulation into a separate process which runs setuid root (through a > setuid C binary, sudo, et cetera) and performs the necessary = validation. > That way, for example, the only thing with which your backup script > would have to concern itself is in asking that a particular snapshot = be > mounted, and being handed back a fully populated directory upon which = to > operate. >=20 > I'm sure there are other ways it can be handled, but that is the one > that springs immediately to mind. >=20 thanks, yes, there are many other ways to handle this, I wanted to avoid = giving root access to the user or the script by delegating the = permissions with the available infrastructure. Also, there are certain = considerations when snapshotting some datasets (where a database lives), = and regarding snapshot frequency (not all datasets snapshots are done at = the same frequency). Best wishes, G. Marcus > --=20 > Fuzzy love, > -CyberLeo > Technical Administrator > CyberLeo.Net Webhosting > http://www.CyberLeo.Net > >=20 > Furry Peace! - http://www.fur.com/peace/