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