Date: Thu, 29 May 2014 15:09:09 +0200 From: Guillermo Marcus <guillermo.marcus@gmail.com> To: CyberLeo Kitsana <cyberleo@cyberleo.net> Cc: freebsd-questions@FreeBSD.org Subject: Re: Mounting a ZFS snapshot by another user Message-ID: <843804C5-2D6E-4E7C-B2DF-858BD2E8B8AA@gmail.com> In-Reply-To: <5387154F.5040502@cyberleo.net> References: <80D52646-2377-447F-BBC4-BEF642585391@gmail.com> <5387154F.5040502@cyberleo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29 May 2014, at 13:09, CyberLeo Kitsana <cyberleo@cyberleo.net> = 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 > <snip> >=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 > <snip> >=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 > <CyberLeo@CyberLeo.Net> >=20 > Furry Peace! - http://www.fur.com/peace/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?843804C5-2D6E-4E7C-B2DF-858BD2E8B8AA>