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