On 07/23/2014 04:04 PM, Stephen Thompson wrote: > > > Redhat 6.5 x86_64
OK, that is a particularly tricky system as they have added additional system security which does not permit certain sequences of API calls even as root which other Linux OSes permit :-( I.e. we test on the latest debian/ubuntu and the code works, but not on RHEL 6.x ... I will look at the code as I may have a patch that will help, but I don't remember it having to do with the setuid bit. I recommend that you submit a bug report on this, because if I get distracted this weekend, I might miss coming back to this problem. With a bug report, it remains very visible until it is corrected. Best regards, Kern > > 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 > ------------------------------------------------------------------------------ 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
