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 <hoogendyk@bio.umass.edu> --------------- ---------------- 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: /tmp/ /var/tmp/ / 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 backup::::type=role;profiles=Dump # grep Dump /etc/security/prof_attr Dump:::Tape Backup User: # grep Dump /etc/security/exec_attr Dump:suser:cmd:::/usr/lib/fs/ufs/ufsdump:euid=0;gid=sys Dump:suser:cmd:::/usr/lib/fs/ufs/fssnap:euid=0;gid=sys 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 <hoogendyk@bio.umass.edu> --------------- _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers ---------------- 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 necessary. 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> <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 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 <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/sunmanagersReceived 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