<div dir="ltr">I agree -- I just don't know how to accomplish that with my constraints and under Solaris 11.<div><br></div><div>Specifically, "backup" is easy and well-understood, for the most part. The thing is, I'm using ZFS file systems, and using a</div><div>zfs send file-system | ssh remote-site "zfs receive file-system"</div><div>kind of thing for backup. I don't know how to make that work without "root" and without manual entry of passwords.</div><div><br></div><div>Or put another way, if I make "root" a regular account instead of a "role" and put the appropriate SSH keys in place, I can put this into a script and everything works. I just don't want to use "root" for this, but I haven't been able to figure out how to use any other account due to missing permissions/privileges. Ack.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 4, 2015 at 10:16 AM, Gilles Detillieux <span dir="ltr"><<a href="mailto:grdetil@scrc.umanitoba.ca" target="_blank">grdetil@scrc.umanitoba.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
My own inclination would be to avoid ACLs and a special non-root
account with fairly unrestricted access privileges. Instead, I'd
make the backup procedure into a fairly tightly constrained script
that would be runnable under "sudo". I think that would be less of
a maintenance headache, and likely more secure with less
possibilities for unforeseen information leakage. When an account
can read anything at all on a filesystem, there are often many ways
of leveraging that into greater access privileges - e.g. access to
ssh private keys.<div><div class="h5"><br>
<br>
<div>On 04/05/2015 9:59 AM, Kevin McGregor
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">I suppose I could put a new ACL on every
file/directory on the system. Presumably there's a way to just
add it to the top level and have it propagate all the way down.
But then again this is Solaris 11, which is exclusively ZFS, and
there are *many* file systems. It would be hard to ensure every
file system (and descendants) *always* gets the "backup" ACL
added to it in a timely fashion.
<div><br>
</div>
<div>That's why I was wondering if there was a "Backup Operator"
type of group. I suspect there isn't such a thing. Likely my
only option is the "backup ACL" approach, manually marking
everything readable by the backup account I choose. I'm not
especially concerned about performance or disk space. ;-)</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, May 4, 2015 at 8:25 AM, Trevor
Cordes <span dir="ltr"><<a href="mailto:trevor@tecnopolis.ca" target="_blank">trevor@tecnopolis.ca</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 2015-05-04 Kevin McGregor wrote:<br>
> Is that possible/feasible? In Windows, there's a
group called "Backup<br>
> Operator" which does something like this. Is the only
alternative in<br>
> Solaris to make the account a member of the "root"
group? I don't care<br>
> about e.g. device files and the like. I just want the
account to be<br>
> able to back up regular ZFS user-type file systems.<br>
<br>
</span>That's a perennial UNIX question. I'd like to know
the answer too!<br>
<br>
Personally, on Linux boxes where groups aren't used at all
for user<br>
files I want backed up (they are all just Samba shared as
the owner), I<br>
use samba settings to ensure all files are group "backup" or
similar<br>
and group readable. Cheesy, but it works because I 100%
control access<br>
to those files via limited daemons.<br>
<br>
If your situation isn't similar (i.e. you are using groups
for something<br>
meaningful, or want to backup whole-systems like including
/etc) then<br>
that is useless.<br>
<br>
I'm sure there's an ACL solution, and I'm (pretty) sure
Solaris has<br>
ACL's. However, something about making a zillion ACL's just
to do<br>
backups rubs me the wrong way. Sure, if the ACL's are small
enough<br>
they'll just get stored in the inode (I think), but I'd sure
hate to<br>
waste a fs block just for an ACL if it didn't (if there
already were<br>
ACL's on the files, selinux, etc).<br>
<br>
I hope some other members will give a more useful answer...<br>
<br>
(It would be nice if there was a standard, automatic UNIX
account called<br>
root-ro!)<br>
<br>
(Oh ya, and dump/restore should be able to bypass all inode
user/group<br>
restrictions, but use at your own risk.)<br>
_______________________________________________<br>
Roundtable mailing list<br>
<a href="mailto:Roundtable@muug.mb.ca" target="_blank">Roundtable@muug.mb.ca</a><br>
<a href="http://www.muug.mb.ca/mailman/listinfo/roundtable" target="_blank">http://www.muug.mb.ca/mailman/listinfo/roundtable</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Roundtable mailing list
<a href="mailto:Roundtable@muug.mb.ca" target="_blank">Roundtable@muug.mb.ca</a>
<a href="http://www.muug.mb.ca/mailman/listinfo/roundtable" target="_blank">http://www.muug.mb.ca/mailman/listinfo/roundtable</a>
</pre>
</blockquote>
<br>
</div></div><span class="HOEnZb"><font color="#888888"><pre cols="72">--
Gilles R. Detillieux E-mail: <a href="mailto:grdetil@scrc.umanitoba.ca" target="_blank"><grdetil@scrc.umanitoba.ca></a>
Spinal Cord Research Centre WWW: <a href="http://www.scrc.umanitoba.ca/" target="_blank">http://www.scrc.umanitoba.ca/</a>
Dept. of Physiology and Pathophysiology, Faculty of Health Sciences,
Univ. of Manitoba Winnipeg, MB R3E 0J9 (Canada)
</pre>
</font></span></div>
<br>_______________________________________________<br>
Roundtable mailing list<br>
<a href="mailto:Roundtable@muug.mb.ca">Roundtable@muug.mb.ca</a><br>
<a href="http://www.muug.mb.ca/mailman/listinfo/roundtable" target="_blank">http://www.muug.mb.ca/mailman/listinfo/roundtable</a><br>
<br></blockquote></div><br></div>