[Summary] ufsdump, solaris 9 & RBAC not working correctly

hoogendyk_at_bio.umass.edu

Date: Fri, 29 Apr 2005 16:52:13 -0400
To: Sun Managers List <sunmanagers@sunmanagers.org>


-- 
  ---------------------------------------------
  Bill R. Williams               <brw@etsu.edu>
  ------------------------ ETSU Library Systems
---------------- My Reply to Bill R. Williams ----------------
Subject: Re: ufsdump, solaris 9 & RBAC not working correctly
Date: Thu, 28 Apr 2005 12:36:26 -0400
From: Chris Hoogendyk <hoogendyk@bio.umass.edu>
To: Bill R. Williams <brw@etsu.edu>
References: <4270EB6A.3060801@bio.umass.edu> 
<20050428141013.GA24653@brwms.etsu.edu>
Bill,
Thanks for the reply. It's the only one I've gotten. Very informative.
It may actually answer the question, although now I have to figure out a
solution.
The /etc/security/exec_attr specifications for the role I created are to
run ufsdump with euid=0. Basically, then, this is no change from the
application being suid in the first place. By Casper ***'s comments and
your explanation, ufsdump is doing most of its processing as user/role
"backup" rather than as root. Since one of the things it does is to
create a directory in /tmp with 0 privileges and then try to create a
subdirectory in that directory, one must assume that either ufsdump is
intended to be run as root or that this is a bug. However, if it was
intended only to be run as root, then it wouldn't be suid root. So, it
must be a bug.
I suppose my next task is to try to find what it is doing and add to the
role exec_attr so that whatever it is runs as root. I assume RBAC is low
level enough that it will work even from inside a binary.
Ok, actually found a bug report 4961690 posted March 30, 2005. Can't
find a corresponding patch.
---------------
Chris Hoogendyk
-
    O__  ---- Systems Administrator
   c/ /'_ --- Biology Department
  (*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst
<hoogendyk@bio.umass.edu>
---------------
---------------- Bill's Reply Back to Me ----------------
Subject: Re: ufsdump, solaris 9 & RBAC not working correctly
Date: Thu, 28 Apr 2005 16:05:41 -0400
From: Bill R. Williams <brw@etsu.edu>
To: Chris Hoogendyk <hoogendyk@bio.umass.edu>
References: <4270EB6A.3060801@bio.umass.edu> 
<20050428141013.GA24653@brwms.etsu.edu> <4271110A.8060409@bio.umass.edu>
Chris,
In the not really help but FWIW department...
I'm guessing that in most cases 'ufsdump' is run as root;
therefore, bug-reports resulting from non-root use are not as
plentiful.
I think that usually 'ufsdump' is being run to backup a filesystem,
(for instance by i-node) for the purposes of getting a "pure"
representation of the state of the filesystem,  and you simply cannot
get a "pure" filesystem backup if you are not 'root'.
   If Casper is correct about ufsdump being suid=root in order to deal
   with the tape drive, and only the tape drive -- not the disk devices
   -- then the suid=root bit on it will not provide privilege to
   read/write anything, anytime, anywhere.
Actually, no matter what you use you can only backup what you have
permission to read, and if you want to include attributes in your
backup you must be able to read them, too.   (Hint, hint.)
IOW: No matter what you are using, you must have some user set up in
some way to read all aspects you want to preserve of the specified
filesystem.  (I'm not a RBAC guru, so I'll just leave that as that. :-)
That isn't to say you can't get a "fine for what I need" backup using
something besides 'ufsdump' and as a user other than root.  I do this
sort of thing quite often: sometimes I use GNU tar (gtar) and
sometimes I use cpio.  (I pick the utility based on the task at hand.)
BTW: any of them can use a fssnap device if you mount it ro somewhere.
I tend to use 'cpio' for "almost" pure backups because:
*	It allows me fine-grained control over the files which get
	backed up.  This would  do a 'cpio' backup, but omit any
	first level ./tmp/* files while keeping the ./tmp entry.
		cd /FILESYSTEM
		find . -fstype ufs -depth -print \
		| grep -v '^./tmp/' \
		| cpio -o >SOMEWHEREnotin/FILESYSTEM/SOMEFILE.cpio
	As you can imagine you could have more 'grep's, etc. in there
	to filter out all non-essential junk stuff.  In quick & dirty
	mode, I "find . -depth -print >/tmp/file.list" and then edit
	that file to just feed to cpio:
		cpio -o </tmpfile.list >/tmp/backup.cpio
	And, you *could* add '| gzip' after the cpio instead of
	'>SOMEFILE...'  to compress "on the fly".
*	It is a reasonably portable format which means I *could*
	retrieve a file from it on another system -- possibly even a
	Linux system.
*	Sun uses 'cpio' for their stuff.  For example...
  	In Solaris9 the part of a flash archive (flar) that contains
	the backup is a 'cpio' container!  IOW:  cpio is available at
	jumpstart/boot time.
Actually, I frequently use the 'cpio' technique to backup certain data
through an ssh pipe from one Solaris9 system to another.  Often the
user running the backup (source) is root, but the target user (on the
receiving system) is NEVER root!
My biggest tip for any backup (ufsdump, cpio, gtar, ...) is when
writing to anything NOT a local file is to specify the blocksize
explicitly.  (In the case of a tape drive give it the biggest
blocksize the drive will allow).  And RECORD the blocksize used; it'll
save you a lot of aggravation later.  (Some utilities want the same
blocksize coming in as they "know" they wrote going out.)
But, you may already know all that and wasted your time reading this
whole thing.   Or you may be able to point out some flaws in my
methods which will prevent me from shooting myself in the foot.
-- 
  ---------------------------------------------
  Bill R. Williams               <brw@etsu.edu>
  ------------------------ ETSU Library Systems
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers