[RndTbl] Solaris/UNIX root-like file access

Gilles Detillieux grdetil at scrc.umanitoba.ca
Mon May 4 10:16:07 CDT 2015


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
> 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/071d1c5e/attachment-0001.html>


More information about the Roundtable mailing list