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