Jump to content
Sign in to follow this  
iwelt

Restoring files with SUID or SGID not working

Recommended Posts

I have a problem with restoring files on linux clients.

 

Files with SUID or SGID set will not be restored correctly if one of owner or group of the file is NOT root.

 

 

Here is an example:

 

Original Files:

retrotest:/test# l misc/

total 3172

drwxr-xr-x 2 root root 4096 2005-07-05 16:08 sbin

-rwxr-s--- 1 nobody nogroup 265880 2005-07-05 18:23 test_sgid-nobody_nogroup

-rwxr-s--- 1 nobody root 265880 2005-07-05 18:23 test_sgid-nobody_root

-rwxr-s--- 1 root nogroup 265880 2005-07-05 18:24 test_sgid-root_nogroup

-rwxr-s--- 1 root root 265880 2005-07-05 18:24 test_sgid-root_root

-rwsr-x--- 1 nobody nogroup 265880 2005-07-05 18:15 test_suid-nobody_nogrooup

-rwsr-x--- 1 nobody root 265880 2005-07-05 18:20 test_suid-nobody_root

-rwsr-x--- 1 root nogroup 265880 2005-07-05 18:15 test_suid-root_nogroup

-rwsr-x--- 1 root root 265880 2005-07-05 18:15 test_suid-root_root

-rwsr-s--- 1 nobody nogroup 265880 2005-07-05 18:15 test_suid_sgid-nobody_nogroup

-rwsr-s--- 1 nobody root 265880 2005-07-05 18:20 test_suid_sgid-nobody_root

-rwsr-s--- 1 root nogroup 265880 2005-07-05 18:15 test_suid_sgid-root_nogroup

-rwsr-s--- 1 root root 265880 2005-07-05 18:15 test_suid_sgid-root_root

 

 

Restored Files:

retrotest:/test# l misc/

total 3172

drwxr-xr-x 2 root root 4096 2005-07-05 16:08 sbin

-rwxr-x--- 1 nobody nogroup 265880 2005-07-05 18:23 test_sgid-nobody_nogroup

-rwxr-x--- 1 nobody root 265880 2005-07-05 18:23 test_sgid-nobody_root

-rwxr-x--- 1 root nogroup 265880 2005-07-05 18:24 test_sgid-root_nogroup

-rwxr-s--- 1 root root 265880 2005-07-05 18:24 test_sgid-root_root

-rwxr-x--- 1 nobody nogroup 265880 2005-07-05 18:15 test_suid-nobody_nogrooup

-rwxr-x--- 1 nobody root 265880 2005-07-05 18:20 test_suid-nobody_root

-rwxr-x--- 1 root nogroup 265880 2005-07-05 18:15 test_suid-root_nogroup

-rwsr-x--- 1 root root 265880 2005-07-05 18:15 test_suid-root_root

-rwxr-x--- 1 nobody nogroup 265880 2005-07-05 18:15 test_suid_sgid-nobody_nogroup

-rwxr-x--- 1 nobody root 265880 2005-07-05 18:20 test_suid_sgid-nobody_root

-rwxr-x--- 1 root nogroup 265880 2005-07-05 18:15 test_suid_sgid-root_nogroup

-rwsr-s--- 1 root root 265880 2005-07-05 18:15 test_suid_sgid-root_root

 

(note:

green = restored correctly

red = not restored correctly

)

 

As you can see, only files which are owned by user root AND group root are restored with the SUID/SGID-bit set correctly.

All other combinations of owner/group leads to missing SUID/SGID-bits on the restored files.

 

I've been running into this using retrospect Multi-Server 6.5.350 and Linux client 6.5.108

 

I've also tried the new retrospect Server 7 and had no luck:

Retrospect Server 7.0.301 with Update 7.0.5.102

Retrospect Client 7.0.109

 

Operating systems tested:

Server: Windows 2000 Professional, Windows XP Professional

Client: Fedora Core2, Debian 3.1

 

 

Is this is a fatal bug?

Share this post


Link to post
Share on other sites

Hi there!

 

I'm still having this problem and obviously noone can help me.

 

Maybe my english is too bad for describing the problem the right way?

 

 

Thanks in advance

Share this post


Link to post
Share on other sites

hi i,

 

 

 

your english is pretty good. i doubt anybody has tried this.

 

 

 

quick question for you: what's the umask set for on these linux computers for user "nobody" and group "nobody"?

 

 

 

and if you are using a different user/group, what is the umask for them? are they 'allowed' to have setuid/setgid when files are created that they own? i believe not, it would be a HUGE security risk.

 

 

 

Now, if you did a restore of the _entire_ linux computer it would probably work......but i haven't tried this.

Share this post


Link to post
Share on other sites

Hi waltr

 

thank you for your post.

 

Unfortunately I'm not a expert in securing linux so i do not know where to look for the settings you mentioned. Only thing I found is that the default umask is 022.

 

But i don't think thats the point, because this misbehaviour involves files owned by different users/groups

 

Maybe this more "real world" example might show what i mean:

 

 

Retrospect-Test-Files:

total 348

-rwsr-xr-x 1 root root 68440 Sep 18 09:04 mount

-rwsr-xr-- 1 root dip 265880 May 5 2005 pppd

-rwsr-x--- 1 root www-run 10596 Sep 5 13:16 suexec2

 

Restored-Retrospect-Test-Files:

total 348

-rwsr-xr-x 1 root root 68440 Sep 18 09:04 mount

-rwxr-xr-- 1 root dip 265880 May 5 2005 pppd

-rwxr-x--- 1 root www-run 10596 Sep 5 13:16 suexec2

 

 

As mentioned above, SGID/SUID will only be restored correctly if user AND group is root.

 

 

We DID a complete restore and ran into this problem, that's how we found that issue.

After restoring the apache suexec doesn't work neither does postfix or spamassasin.

 

Maybe there is something that i don't see or something i don't know?

 

thanks in advance

Jan

Share this post


Link to post
Share on other sites

hi jan,

 

i've done a full restore of linux before but i haven't seen this issue, that's why i thought it might work. i can run a test on my site & see if i have the same issue.

Share this post


Link to post
Share on other sites

hi jan,

 

 

 

sorry it took me so long. obviously i am not doing this on a production computer. i picked one from the crap pile and it took me a while to figure out that the CD ROM is broken.

 

 

 

now i'm all fixed up w/ SUSE 9.3. where do i find files like this in the default install? or do i have to manually make/change them? give me paths.

 

 

 

edited to add: just let me know when you can. i'll be out of my office tomorrow (wed) but will be back thursday. if i don't hear from you thursday this will have to wait as i am leaving town for a week to visit family.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×