In Solaris 11, "root" by default is a role, not an account you can log into. I'd like to create an account with generally fewer privileges than root -- in fact no privileges at all -- *except* I want to make sure it can read all regular files and directories in order to do a backup.
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.
Feel free to ask me questions to clarify this. I'm probably not explaining it well.
Kevin
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.)
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@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@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
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@tecnopolis.ca mailto:trevor@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@muug.mb.ca <mailto:Roundtable@muug.mb.ca> http://www.muug.mb.ca/mailman/listinfo/roundtable
Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
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@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@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@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
Roundtable mailing listRoundtable@muug.mb.cahttp://www.muug.mb.ca/mailman/listinfo/roundtable
-- Gilles R. Detillieux E-mail: grdetil@scrc.umanitoba.ca grdetil@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@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
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@remote-site "sudo receive-zfs-script"
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@scrc.umanitoba.ca mailto:grdetil@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@tecnopolis.ca <mailto:trevor@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@muug.mb.ca <mailto:Roundtable@muug.mb.ca> http://www.muug.mb.ca/mailman/listinfo/roundtable _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca <mailto:Roundtable@muug.mb.ca> http://www.muug.mb.ca/mailman/listinfo/roundtable-- Gilles R. Detillieux E-mail:<grdetil@scrc.umanitoba.ca> <mailto:grdetil@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@muug.mb.ca <mailto:Roundtable@muug.mb.ca> http://www.muug.mb.ca/mailman/listinfo/roundtable
Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-
Gilles Detillieux -
Kevin McGregor -
Trevor Cordes