[RndTbl] Solaris/UNIX root-like file access

Gilles Detillieux grdetil at scrc.umanitoba.ca
Mon May 4 11:23:35 CDT 2015

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.

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.:

     zfs send file-system | ssh backupuid at remote-site "sudo 

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").

On 04/05/2015 10:34 AM, Kevin McGregor wrote:
> I agree -- I just don't know how to accomplish that with my 
> constraints and under Solaris 11.
> Specifically, "backup" is easy and well-understood, for the most part. 
> The thing is, I'm using ZFS file systems, and using a
> zfs send file-system | ssh remote-site "zfs receive file-system"
> kind of thing for backup. I don't know how to make that work without 
> "root" and without manual entry of passwords.
> 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.
> On Mon, May 4, 2015 at 10:16 AM, Gilles Detillieux 
> <grdetil at scrc.umanitoba.ca <mailto:grdetil at scrc.umanitoba.ca>> wrote:
>     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.
>     On 04/05/2015 9:59 AM, Kevin McGregor wrote:
>>     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.
>>     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. ;-)
>>     On Mon, May 4, 2015 at 8:25 AM, Trevor Cordes
>>     <trevor at tecnopolis.ca <mailto:trevor at tecnopolis.ca>> wrote:
>>         On 2015-05-04 Kevin McGregor wrote:
>>         > Is that possible/feasible? In Windows, there's a group
>>         called "Backup
>>         > Operator" which does something like this. Is the only
>>         alternative in
>>         > Solaris to make the account a member of the "root" group? I
>>         don't care
>>         > about e.g. device files and the like. I just want the
>>         account to be
>>         > able to back up regular ZFS user-type file systems.
>>         That's a perennial UNIX question.  I'd like to know the
>>         answer too!
>>         Personally, on Linux boxes where groups aren't used at all
>>         for user
>>         files I want backed up (they are all just Samba shared as the
>>         owner), I
>>         use samba settings to ensure all files are group "backup" or
>>         similar
>>         and group readable.  Cheesy, but it works because I 100%
>>         control access
>>         to those files via limited daemons.
>>         If your situation isn't similar (i.e. you are using groups
>>         for something
>>         meaningful, or want to backup whole-systems like including
>>         /etc) then
>>         that is useless.
>>         I'm sure there's an ACL solution, and I'm (pretty) sure
>>         Solaris has
>>         ACL's.  However, something about making a zillion ACL's just
>>         to do
>>         backups rubs me the wrong way.  Sure, if the ACL's are small
>>         enough
>>         they'll just get stored in the inode (I think), but I'd sure
>>         hate to
>>         waste a fs block just for an ACL if it didn't (if there
>>         already were
>>         ACL's on the files, selinux, etc).
>>         I hope some other members will give a more useful answer...
>>         (It would be nice if there was a standard, automatic UNIX
>>         account called
>>         root-ro!)
>>         (Oh ya, and dump/restore should be able to bypass all inode
>>         user/group
>>         restrictions, but use at your own risk.)
>>         _______________________________________________
>>         Roundtable mailing list
>>         Roundtable at muug.mb.ca <mailto:Roundtable at muug.mb.ca>
>>         http://www.muug.mb.ca/mailman/listinfo/roundtable
>>     _______________________________________________
>>     Roundtable mailing list
>>     Roundtable at muug.mb.ca  <mailto:Roundtable at muug.mb.ca>
>>     http://www.muug.mb.ca/mailman/listinfo/roundtable
>     -- 
>     Gilles R. Detillieux              E-mail:<grdetil at scrc.umanitoba.ca>  <mailto:grdetil at scrc.umanitoba.ca>
>     Spinal Cord Research Centre       WWW:http://www.scrc.umanitoba.ca/
>     Dept. of Physiology and Pathophysiology, Faculty of Health Sciences,
>     Univ. of Manitoba  Winnipeg, MB  R3E 0J9  (Canada)
>     _______________________________________________
>     Roundtable mailing list
>     Roundtable at muug.mb.ca <mailto:Roundtable at muug.mb.ca>
>     http://www.muug.mb.ca/mailman/listinfo/roundtable
> _______________________________________________
> Roundtable mailing list
> Roundtable at muug.mb.ca
> http://www.muug.mb.ca/mailman/listinfo/roundtable

Gilles R. Detillieux              E-mail: <grdetil at scrc.umanitoba.ca>
Spinal Cord Research Centre       WWW:    http://www.scrc.umanitoba.ca/
Dept. of Physiology and Pathophysiology, Faculty of Health Sciences,
Univ. of Manitoba  Winnipeg, MB  R3E 0J9  (Canada)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.muug.mb.ca/pipermail/roundtable/attachments/20150504/106e0d45/attachment-0001.html>

More information about the Roundtable mailing list