Redhat 6.5 x86_64
On 7/23/14 12:50 AM, Kern Sibbald wrote: > Different Linux OSes have very different behaviors, which OS are you > running (distribution and version)? > > On 07/23/2014 12:10 AM, Stephen Thompson wrote: >> I'm running 7.0.4. >> >> >> >> Here's an example... >> >> (before backup) >> # ls -ld /bin >> dr-xr-xr-x 2 root root 4096 Jul 22 09:56 /bin >> # ls -l /bin/ping >> -rwsr-xr-x 1 root root 40760 Sep 17 2013 /bin/ping >> >> (after restore selecting file /bin/ping) >> # ls -ld /bin >> drwsr-xr-x 2 root root 4096 Jul 22 14:38 bin >> # ls -l /bin/ping >> -rwxr-xr-x 1 root root 40760 Sep 17 2013 ping >> >> (after restore selecting file /bin/ping and directory /bin) >> # ls -ld /bin >> dr-xr-xr-x 2 root root 4096 Jul 22 14:38 bin >> # ls -l /bin/ping >> -rwxr-xr-x 1 root root 40760 Sep 17 2013 ping >> >> >> In the first restore case, looks like the dir has user-write permissions >> as well, which isn't right, but perhaps that comes from the umask of the >> restore since the directory wasn't part of the restore selection. >> However, the setuid bit certainly wouldn't be coming from the umask. >> I'm jumping to the conclusion that whatever's doing the setuid bit is >> messing up and doing it to the parent directory instead of to the file. >> >> Stephen >> >> >> >> >> >> On 7/22/14 2:58 PM, Stephen Thompson wrote: >>> >>> Sorry if I have not researched this enough before bringing it to the >>> list, but what I'm seeing is very odd. Someone else must have run into >>> this before me. >>> >>> If I restore a setuid or setgid file, the file is restored without the >>> setuid/setgid bit set. However, the directory containing the file >>> (which did not have it's setuid/setgid bit set during the backup) winds >>> up with the setuid/setgid bit being set. >>> >>> If I restore both the directory and the file, the directory ends up with >>> the proper "non-setuid/setgid" attributes, but the file once again ends >>> up without the setuid/setgid bit set. I'm assuming the directory has >>> the bit set during an interim stage of the restore, but is then properly >>> set when it's attributes are set during the restore (which must happen >>> after the files that it contains). >>> >>> I can't say authoritatively, but I don't believe this is the way bacula >>> used to behave for me. And to say the least, this is far from >>> acceptable. I discovered this during a bare metal restore, and have >>> loads of issues from no setuid or setgid bits being set on the restored >>> system. >>> >>> thanks, >>> Stephen -- Stephen Thompson Berkeley Seismological Laboratory step...@seismo.berkeley.edu 215 McCone Hall # 4760 510.214.6506 (phone) University of California, Berkeley 510.643.5811 (fax) Berkeley, CA 94720-4760 ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users