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

From: Chris Hoogendyk <hoogendyk_at_bio.umass.edu>
Date: Fri Apr 29 2005 - 16:52:13 EDT
Didn't get any direct answers to my question, but I got some very good 
explanatory information from the one person (Bill R. Williams 
<brw@etsu.edu>) who replied, and that lead me to the answers I needed.

Bottom line, bug 4961690 posted on Sun on March 30, 2005. No 
corresponding patch that I could find. Workaround - run ufsdump as root 
until patch is available. Since I'm using a remote tape drive for this 
server, and I don't want to have root logging in on the remote server, I 
did it this way:

   /usr/lib/fs/ufs/ufsdump 0cafNu cat1 - /dev/rdsk/c0t0d0s3 \
     `/usr/lib/fs/ufs/fssnap -o raw,bs=/export/home/scratch,unlink / ` \
      | su - backup -c 'ssh remoteserver "dd obs=64b of=/dev/rmt/0n"'

of course, embedded in a larger script with all the other appropriate 
stuff like "fssnap -d /", etc. and key exchange setup for backup user.

original message and exchanges below chronologically.


Chris Hoogendyk

    O__  ---- Systems Administrator
   c/ /'_ --- Biology Department
  (*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst



---------------- Original Message Posted to List ----------------

Subject: ufsdump, solaris 9 & RBAC not working correctly
Date: Thu, 28 Apr 2005 09:55:54 -0400
From: Chris Hoogendyk <hoogendyk@bio.umass.edu>
To: Sun Managers List <sunmanagers@sunmanagers.org>

I've found brief discussions on a couple of lists attributing the error

   Unable to create temporary directory in any of the
   directories listed below:
   Please correct this problem and rerun the program.

to a "bug" in ufsdump in Solaris 9. One person said he replace the
Solaris 9 ufsdump binary with the Solaris 8 ufsdump binary and it worked
without the error.

the error seems to be cause by the creation of a directory with 0
permissions on /tmp and then an attempt to create a subdirectory under
that. root can do it, but if you run ufsdump as non-root, it cannot,
even though ufsdump is suid root.

in one thread, Casper Dik said
   "The only thing ufsdump/ufsrestore use set-uid root for is
    to use rcmd(3) for remote tape style dumping. They
    do not run with euid == 0 when doing anything else."

I don't really get that. I thought suid was suid.

Anyway, I've created a role "backup" with the following specs:

   # grep backup /etc/passwd
   backup:x:7000:7000:Tape Backup:/u1/home/.backup:/bin/pfksh

   # grep backup /etc/user_attr

   # grep Dump /etc/security/prof_attr
   Dump:::Tape Backup User:

   # grep Dump /etc/security/exec_attr

If I 'su - backup' and do a ufsdump, I still get the same error
described above. Presumably, I'm not only running ufsdump as root as per
the role, but ufsdump is also suid root.

I know the role is working, because I got a permission denied on the
fssnap before I had it set up, and now the fssnap works. In both cases,
I'm using the full path to the binary and not the symlink.

I really want to use RBAC rather than run this whole thing as root.

Any ideas?


Chris Hoogendyk

    O__  ---- Systems Administrator
   c/ /'_ --- Biology Department
  (*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst


sunmanagers mailing list

---------------- First Response from Bill R. Williams ----------------

Subject: Re: ufsdump, solaris 9 & RBAC not working correctly
Date: Thu, 28 Apr 2005 10:10:13 -0400
From: Bill R. Williams <brw@etsu.edu>
To: Chris Hoogendyk <hoogendyk@bio.umass.edu>
References: <4270EB6A.3060801@bio.umass.edu>

Hi Chris,

I can't speak to the RBAC, but perhaps I can clear up one thing for
you.  Referring to suid program remarks you said:

  > I don't really get that. I thought suid was suid.

It is; however, a suid program may drop/regain the suid privileges any
time it wants to.  Any well-behaved program designed to run with
suid=root had BETTER drop priv and regain only when absolutely

Or more specifically:
A program (task, job, whatever) has a REAL uid and an EFFECTIVE uid
which in most cases are the same -- the uid of the user running the
program.  A suid program run by some user, spawns with the euid of its
owner and the ruid of the user which ran it.  IOW: it is "effectively"
running as the program owner.  THE FIRST THING such a program is
supposed to do is save euid and switch to ruid so that it is now
running as the user.  It should switch back to the euid ONLY for
operations that require the privilege of the euid, and as soon as the
operation is complete it should drop back to ruid.

This is how things like Apache start as root then run as some other
user -- apache, httpd, or nobody.

Of course, if 'root' is running a program, it doesn't really matter
what the suid is or whether the program "drops privilege" -- it's
always running as root.

Maybe this helps with the suid is suid thing.
It is, but only as long as it wants to be.
  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> 


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

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 Dik'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



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


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

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.
		find . -fstype ufs -depth -print \
		| grep -v '^./tmp/' \
	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
Received on Fri Apr 29 16:53:56 2005

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:46 EST