Gil,

I'm confused, why would suid be needed on ufsdump - isn't it run
beneith the amanda program (/usr/local/libexec/) rundump which is suid ?

For recovery, personally I use amrestore and pipe it to the required
utility so as long as I can figure that out (and its imbedded into the
first block on of the archive) its not a big deal.


On Thu, Feb 24, 2005 at 01:14:03PM -0500, Gil Naveh wrote:
> Thanks for the help,
> 
> At this point it seems that the best way for us is to switch from ufsdump to
> gnutar.
> But before doing so - what will happen with the backups that I did so far?
> (I backed our data on a tape drive).
> Does ufsdump and gnutar stores the data the same way? (Does ufsdump level
> 0,1... is identical to gnutar level 0,1...) Or does it store the data on a
> different format?
> Does Gnutar is going to store the data twice or is it going to overwrite the
> data that was stored by ufsdump?
> 
> Any other concerns that I should keep in mind before switching from ufsdump
> to gnutar?
> 
> Thanks,
> gil
> 
> -----Original Message-----
> From: owner-amanda-users AT amanda DOT org
> [mailto:owner-amanda-users AT amanda DOT org]On Behalf Of Todd Kover
> Sent: Thursday, February 24, 2005 12:37 PM
> To: amanda-users AT amanda DOT org
> Subject: Re: Amanda - unable to create temporary directory
> 
> 
> 
> Jon LaBadie said:
> 
>  > On my system /usr/sbin/ufsdump is a symbolic link to
> /usr/lib/fs/ufs/ufsdump.
>  > The latter program is root-owned, set-uid.  Perhaps yours has been
> altered.
>  >
>  > $ ls -l /usr/lib/fs/ufs/ufsdump
>  > -r-sr-xr-x  1 root  bin   83820 Apr 12  2004 /usr/lib/fs/ufs/ufsdump
> 
> We actually strip the setuid bit on ufsdump and this seems to work in
> most circumstances.
> 
> We had this problem every night on one specific solaris 9 system, and
> no other sol9 or sol8 systems (and our amanda client is installed via a
> package, so it's the same across all machines).  The solaris boxes are
> also installed from the same jumpstart images, so they should all behave
> the same.
> 
> This error comes from ufsdump, and near as I've been able to tell,
> ufsdump is creating a directory named something like '.rlg.zyaaGR in
> each of /tmp and /var/tmp (and failing to be able to in / since it's not
> running as root, the jibberish after .rlg. changes with each run).  This
> directory is called with mode 000 and then ufsdump attempts to create a
> file in it, which fails and generates that error message.
> 
> I wasn't able to get ufsdump to behave better (nor did I look for
> a patch or try to reset ufsdump to being setuid again) but on that
> specific system we had amanda incorrectly configured to backup something
> other than the mountpoint of the filesystem, but something inside the
> filesystem (that is, instead of /export/home it was /export/home/foo/bar
> where the filesystem was mounted on /export/home).
> 
> Switching this to the mountpoint made the error go away.  There may be
> some limitations in ufsdump that cause you only be able to use ufsdump
> this way if you're root (though sounsd lke a bug).
> 
> If you're doing this, and doing it on purpose, I'd suggest using gnutar
> instead of dump since incremental dumps don't work right except on
> filesystem boundaries.
> 
> If you're not doing this and actually backing up a mountpoint, then
> maybe the above info will help track it down. (perhaps the setuid bit,
> as Jon suggests).
> 
> -Todd
> 
---
   Brian R Cuttler                 brian.cuttler AT wadsworth DOT org
   Computer Systems Support        (v) 518 486-1697
   Wadsworth Center                (f) 518 473-6384
   NYS Department of Health        Help Desk 518 473-0773