Moreover, the fact that the number of snapshots allowed on a filesystem is limited to a handful (src/sys/ufs/ffs/README.snapshot says 20) makes it possible for normal users to disrupt dump -L and other important operations that require snapshots.
Alternative 2 seems a lot more sensible. Just my 2 KRW (1 USD ~= 1250 KRW) :D, Eugene On Thu, Jan 30, 2003 at 05:15:01PM -0600, Jacques A. Vidrine wrote: > On Wed, Jan 29, 2003 at 06:17:31PM -0800, Kirk McKusick wrote: > > Alternative 1 `usermount' > > The first would be > > to change the default for vfs.usermount == 1 and then have dump -L > > create the snapshot in a directory owned by "operator" (or by > > whatever user runs the dumps). Then the snapshot could be created, > > used, and deleted by that user. > > Alternative 2 `/sbin/snapshot' > > The other alternative would be to > > create a setuid-to-root program that would take a snapshot and > > chown it to the user that does dumps. This setuid program could > > then be invoked by dump -L to create a snapshot for it. > > Despite a distaste for setuid executables, I think I'd prefer a simple > /sbin/snapshot setuid program. Primarily, enabling `vfs.usermount' > gives more privileges to more users than I'm comfortable with. > Secondarily, /sbin/snapshot may be useful on its own. > > Cheers, > -- > Jacques A. Vidrine <[EMAIL PROTECTED]> http://www.celabo.org/ > NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos > [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
