root ownership randomly

root ownership randomly

Post by so.. » Sun, 31 Dec 1899 09:00:00



We have a few linux systems running redhat 5.2 in a
net composed also of SGI and SUN workstation. The linux
boxes export their files to every machines on the net.
When working on a remote system, a normal user has created
a few times files or directories owned by root (this
user does not know the super user password) on the
filesystems managed by linux.

I have no idea why this is happening and how this
can be fixed. Is it linked to the way I export
the filesystems? I don't think this has
happened when working locally on the linux box. Any idea?

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

 
 
 

root ownership randomly

Post by Matt Templeto » Sun, 31 Dec 1899 09:00:00



> We have a few linux systems running redhat 5.2 in a
> net composed also of SGI and SUN workstation. The linux
> boxes export their files to every machines on the net.
> When working on a remote system, a normal user has created
> a few times files or directories owned by root (this
> user does not know the super user password) on the
> filesystems managed by linux.

> I have no idea why this is happening and how this
> can be fixed. Is it linked to the way I export
> the filesystems? I don't think this has
> happened when working locally on the linux box. Any idea?

> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.

Your best bet is to ask this question in a technical group such as
comp.os.linux.networking.

 
 
 

root ownership randomly

Post by Chad Myer » Sun, 31 Dec 1899 09:00:00


Yeah, because most of the people in this group don't really know
about networking or OSs in general, that's why they're linux
advocates =)

Chad



> > We have a few linux systems running redhat 5.2 in a
> > net composed also of SGI and SUN workstation. The linux
> > boxes export their files to every machines on the net.
> > When working on a remote system, a normal user has created
> > a few times files or directories owned by root (this
> > user does not know the super user password) on the
> > filesystems managed by linux.

> > I have no idea why this is happening and how this
> > can be fixed. Is it linked to the way I export
> > the filesystems? I don't think this has
> > happened when working locally on the linux box. Any idea?

> > Sent via Deja.com http://www.deja.com/
> > Share what you know. Learn what you don't.

> Your best bet is to ask this question in a technical group such as
> comp.os.linux.networking.

 
 
 

root ownership randomly

Post by Chris Costell » Sun, 31 Dec 1899 09:00:00



> Yeah, because most of the people in this group don't really know
> about networking or OSs in general, that's why they're linux
> advocates =)

   I know about file systems, read this newsgroup AND am not a
Linux advocate!  Whee!  I get to be an exception.

Quote:> Chad

--
|Chris Costello
|All computers run at the same speed...with the power off.
`---------------------------------------------------------
 
 
 

root ownership randomly

Post by Matt Templeto » Sun, 31 Dec 1899 09:00:00



> Yeah, because most of the people in this group don't really know
> about networking or OSs in general, that's why they're linux
> advocates =)

> Chad

No, I just did not want the guy to get trolled by all the WinTrolls in
the group, So, I pointed him to a more appropriate place to ask a
technical question. And what happens? I get WinTrolled! By the way,
there are several ways that such a situation as the poster described
could happen, all that I know of are human error. It may have taken some
discussion back and forth so he would be better off in a technical news
group any way. If I see him post there I'll try to help.
 
 
 

root ownership randomly

Post by Navindra Umane » Sun, 31 Dec 1899 09:00:00



> can be fixed. Is it linked to the way I export
> the filesystems? I don't think this has

How do you export the filesystems?  By default root should probably be
prevented from reading/writing files on the filesystem.

-N.
--
"These download files are in Microsoft Word 6.0 format.  After unzipping,
these files can be viewed in any text editor, including all versions of
Microsoft Word, WordPad, and Microsoft Word Viewer."  [Microsoft website]
           < http://www.cs.mcgill.ca/~navindra/editors/ >

 
 
 

root ownership randomly

Post by The Ghost In The Machi » Sun, 31 Dec 1899 09:00:00




Quote:>We have a few linux systems running redhat 5.2 in a
>net composed also of SGI and SUN workstation. The linux
>boxes export their files to every machines on the net.
>When working on a remote system, a normal user has created
>a few times files or directories owned by root (this
>user does not know the super user password) on the
>filesystems managed by linux.

>I have no idea why this is happening and how this
>can be fixed. Is it linked to the way I export
>the filesystems? I don't think this has
>happened when working locally on the linux box. Any idea?

>Sent via Deja.com http://www.deja.com/
>Share what you know. Learn what you don't.

Several issues here.

1: The directories being compromised may have group write permissions,
   group 'root' (or 'wheel').  If this is the case, it's very easy to
   create a setgid script (as root: mkdir /tmp/duh; chmod 2777 /tmp/duh;
   as user: vi /tmp/duh/disaster; chmod 2755 /tmp/duh/disaster) and
   /tmp/duh/disaster is now a setgid script.  This is not as dangerous
   as a setuid script, but it's bad enough.  (It does require root
   permissions, admittedly, on the Linux box -- although if a
   writable directory with the right (write + setgid) permissions
   is lying around, there's a potential problem waiting to happen.)

   I was unable to change the permissions of /tmp/duh to create
   root-owned files, however.  I guess that's a good thing. :-)

   In this case, the fix is simple: chmod g-w the affected directories.
   Also, look for suspicious setuid or setgid scripts; these can
   be identified by something like

   cd /
   ls -lR | grep '^-..[-sx]..[-sx]..[-tx]' | grep -v '^-..[-x]..[-x]..[-x]'

   (which checks for scripts and executables with one of the special
   bits set).

   Note that a number of games which use libsvga must be
   setuid or setgid, in order to get the required access to
   use the console.  Definitely annoying.

2. Check to ensure that all entries in /etc/exports do NOT have
   no_root_squash set!  (The default is to squash root into nobody;
   this means that if a box were compromised, other boxes remotely
   mounted via NFS won't be as badly affected.)

   'man exports' for more info on the precise format.

   (Side note: I'd be surprised if no one has tried throwing specially-
   formatted packets at an NFS server, masquerading as root trying
   to open and write to a file.  This is one reason why no_root_squash
   should only be used on *very* trustworthy networks.)

I'm not sure what else to advise at this time.

--

 
 
 

root ownership randomly

Post by so.. » Sun, 31 Dec 1899 09:00:00






> >We have a few linux systems running redhat 5.2 in a
> >net composed also of SGI and SUN workstation. The linux
> >boxes export their files to every machines on the net.
> >When working on a remote system, a normal user has created
> >a few times files or directories owned by root (this
> >user does not know the super user password) on the
> >filesystems managed by linux.

> >I have no idea why this is happening and how this
> >can be fixed. Is it linked to the way I export
> >the filesystems? I don't think this has
> >happened when working locally on the linux box. Any idea?

> >Sent via Deja.com http://www.deja.com/
> >Share what you know. Learn what you don't.

> Several issues here.

> 1: The directories being compromised may have group write permissions,
>    group 'root' (or 'wheel').

If it was the case, the problem would happen locally AND vis NFS access.
It is not the case (the problem happens only via
NFS access) and the directories don't have such group permissions.

Quote:> 2. Check to ensure that all entries in /etc/exports do NOT have
>    no_root_squash set!  (The default is to squash root into nobody;
>    this means that if a box were compromised, other boxes remotely
>    mounted via NFS won't be as badly affected.)

This is useful for security purposes but the case I am reporting
does not fall in this category. The user in question is an average
user, well-intentioned, trying to do his work with the minimum of
trouble. I suspect more a bug with NFS. Maybe I don't know where to
look but all the nfs-server RPM packages I can find are Beta version
(2.2beta). Can anybody suggest a place where I can find a non-beta
version or why are they all Beta?

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

 
 
 

1. root ownership randomly

We have a few linux systems running redhat 5.2 in a
net composed also of SGI and SUN workstation. The linux
boxes export their files to every machines on the net.
When working on a remote system, a normal user has created
a few times files or directories owned by root (this
user does not know the super user password) on the
filesystems managed by linux.

I have no idea why this is happening and how this
can be fixed. Is it linked to the way I export
the filesystems? I don't think this has
happened when working locally on the linux box. Any idea?

I am exporting with no_root_squash and this is fine
on our trusted network. The user in question is not superuser
and is well-intentionned. I suspect a bug in NFS. Maybe
I did not search well enough but all the nfs packages
I find are beta (2.2beta)? Where can I find a non-beta
package (or why isn't there a non-beta package) ?

2. XFree86 3.3.3 & S3 ViRGE -- Good News!

3. Multithreaded app randomly quits as non-root

4. about installing SuSE 8.1

5. user ownership and group ownership

6. cron: 0481-087 The c queue maximum run limit has been reached.

7. Cron won't chown file with root ownership,help!

8. Redhat 6.1 and MegaRAID 466

9. Root can't take ownership of a file (REPOST)

10. root setuid script cannot change ownership

11. root ownership

12. root unable to change file ownership

13. SAMBA Q: file ownership is root even with force user = %U