<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I don't really know anything about Solaris - especially recent
    versions - and I don't really understand the difference between root
    as an account and as a "role".  If it's anything like how Mac OS X
    is set up, by default there's no login to root possible, and no "su"
    to root either, because there's no password to access the root
    account, though that can be set up.  On OS X, to do anything as
    root, you use sudo from an account in the wheel group (i.e. the
    adminstrative accounts).  But from those accounts, you can do
    anything as root by prefixing "sudo" to your command, or get a root
    shell using "sudo -s", and providing your own account password.  I
    don't know if roles in Solaris are a similar idea.<br>
    <br>
    In any case, there are always some administrative tasks that will
    require root access, so you need some way to run some commands with
    root privileges.  I've always thought that full file-system backups
    fit in that category.  If you don't want to use root for
    password-free ssh access, then it seems the best approach would be
    to use sudo from a limited-privilege account.  E.g.:<br>
    <br>
        zfs send file-system | ssh backupuid@remote-site "sudo
    receive-zfs-script"<br>
    <br>
    where /etc/sudoers on the remote site allows backupuid to run the
    receive-zfs-script with no password, backupuid's
    .ssh/authorized_keys allows password-less access from root on the
    originating site (possibly constrained to the one command you want
    to allow), and receive-zfs-script runs the command(s) needed to
    receive the backup (even if that's simply "zfs receive
    file-system").<br>
    <br>
    <div class="moz-cite-prefix">On 04/05/2015 10:34 AM, Kevin McGregor
      wrote:<br>
    </div>
    <blockquote
cite="mid:CACBFUzgYJcwDRLAScx6MtfGgc4h4_CK7_fvL_Gs31ZgLOOumFw@mail.gmail.com"
      type="cite">
      <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">&lt;<a moz-do-not-send="true"
              href="mailto:grdetil@scrc.umanitoba.ca" target="_blank">grdetil@scrc.umanitoba.ca</a>&gt;</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">&lt;<a
                            moz-do-not-send="true"
                            href="mailto:trevor@tecnopolis.ca"
                            target="_blank">trevor@tecnopolis.ca</a>&gt;</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>
                            &gt; Is that possible/feasible? In Windows,
                            there's a group called "Backup<br>
                            &gt; Operator" which does something like
                            this. Is the only alternative in<br>
                            &gt; Solaris to make the account a member of
                            the "root" group? I don't care<br>
                            &gt; about e.g. device files and the like. I
                            just want the account to be<br>
                            &gt; 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 moz-do-not-send="true"
                            href="mailto:Roundtable@muug.mb.ca"
                            target="_blank">Roundtable@muug.mb.ca</a><br>
                          <a moz-do-not-send="true"
                            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 moz-do-not-send="true" href="mailto:Roundtable@muug.mb.ca" target="_blank">Roundtable@muug.mb.ca</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true" href="mailto:grdetil@scrc.umanitoba.ca" target="_blank">&lt;grdetil@scrc.umanitoba.ca&gt;</a>
Spinal Cord Research Centre       WWW:    <a moz-do-not-send="true" 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 moz-do-not-send="true"
              href="mailto:Roundtable@muug.mb.ca">Roundtable@muug.mb.ca</a><br>
            <a moz-do-not-send="true"
              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>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Roundtable mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Roundtable@muug.mb.ca">Roundtable@muug.mb.ca</a>
<a class="moz-txt-link-freetext" href="http://www.muug.mb.ca/mailman/listinfo/roundtable">http://www.muug.mb.ca/mailman/listinfo/roundtable</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Gilles R. Detillieux              E-mail: <a class="moz-txt-link-rfc2396E" href="mailto:grdetil@scrc.umanitoba.ca">&lt;grdetil@scrc.umanitoba.ca&gt;</a>
Spinal Cord Research Centre       WWW:    <a class="moz-txt-link-freetext" href="http://www.scrc.umanitoba.ca/">http://www.scrc.umanitoba.ca/</a>
Dept. of Physiology and Pathophysiology, Faculty of Health Sciences,
Univ. of Manitoba  Winnipeg, MB  R3E 0J9  (Canada)
</pre>
  </body>
</html>