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
stephen AT seismo.berkeley DOT 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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users