Mounting /tmp with incorrect attributes

Mounting /tmp with incorrect attributes

Post by ralf.koel.. » Fri, 20 Oct 2000 04:00:00



Hello,

we have on a sparc-machine, running Solaris 2.6, a problem with
mounting of /tmp .
The mount is performed, but the attributes, set to 'rwxrwxrwt sys:sys'
before booting the computer, aren't correct after the mount-procedure.
Is has following attributes : 'rwxrwxr_x root:ids'.
We also set the mount-poimt to the correct values, but normally the
attributes of the mount-point have no influence to the mount-options.
Have somebody seen a similiar effect ?
I haven't found any options, which can given in the vfstab
to determine the attributes like on Linux.

Any ideas will be appreciated.
Thanks in advance.

Ralf Koelmel


Sent via Deja.com http://www.deja.com/
Before you buy.

 
 
 

Mounting /tmp with incorrect attributes

Post by Alberto da Silv » Fri, 20 Oct 2000 04:00:00


Boot to single user (reboot -- -s)
unmount /tmp (if it is mounted)
chmod / chown /tmp
reboot

Alberto


> Hello,

> we have on a sparc-machine, running Solaris 2.6, a problem with
> mounting of /tmp .
> The mount is performed, but the attributes, set to 'rwxrwxrwt sys:sys'
> before booting the computer, aren't correct after the mount-procedure.
> Is has following attributes : 'rwxrwxr_x root:ids'.
> We also set the mount-poimt to the correct values, but normally the
> attributes of the mount-point have no influence to the mount-options.
> Have somebody seen a similiar effect ?
> I haven't found any options, which can given in the vfstab
> to determine the attributes like on Linux.

> Any ideas will be appreciated.
> Thanks in advance.

> Ralf Koelmel


> Sent via Deja.com http://www.deja.com/
> Before you buy.


 
 
 

Mounting /tmp with incorrect attributes

Post by Chris Thomps » Fri, 20 Oct 2000 04:00:00



>we have on a sparc-machine, running Solaris 2.6, a problem with
>mounting of /tmp .
>The mount is performed, but the attributes, set to 'rwxrwxrwt sys:sys'
>before booting the computer,

Excuse me... but how can you say what the attributes of /tmp are before
you have "booted" the system? Pure introspection? Or did you mean "reboot"?

Quote:>                             aren't correct after the mount-procedure.
>Is has following attributes : 'rwxrwxr_x root:ids'.
>We also set the mount-poimt to the correct values, but normally the
>attributes of the mount-point have no influence to the mount-options.
>Have somebody seen a similiar effect ?

If your /tmp is a tmpfs filing system, which is the normal setup, then
the *initial* uid/gid/permissions of its root directory are inherited
from the mount point directory (since Solaris 2.3 or 2.4 or thereabouts).

If they are coming up wrong, the underlying root filing system /tmp
has been sabotaged (and you might want to find out why: inappropriate
activity in single-user mode is one possibility, and that might mean
there's some great mess of files been deposited there being hidden
by the mount in normal running).

Basic correction technique: boot in single-user mode, in which the
/tmp mount will not occur, and sort the mess out from there.

It's possible to do this from a running system, even without unmounting
/tmp, but that's an exercise for the advanced student. I've described
how to do it before in this newsgroup, and will probably do so again if
given the slightest encouragement...

Chris Thompson
Email: cet1 [at] cam.ac.uk

 
 
 

Mounting /tmp with incorrect attributes

Post by Casper H.S. Dik - Network Security Engine » Sat, 21 Oct 2000 04:00:00


[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


>It's a big problem to boot in single-user mode,
>because the system has been delivered to our customer.
>I can only inspect it by modem.
>It would be interesting to know, how I can do a correction
>without unmounting /tmp.

Well, this is rather dangerous and requires a second system:

        share -o rw=system,root=system /

on the "system" do:

        mount brokensystem:/ /mnt (don't mount /tmp)
        chmod 1777 /mnt/tmp

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

Mounting /tmp with incorrect attributes

Post by Chris Thomps » Sat, 21 Oct 2000 04:00:00





[...]

>> If they are coming up wrong, the underlying root filing system /tmp
>> has been sabotaged (and you might want to find out why: inappropriate
>> activity in single-user mode is one possibility, and that might mean
>> there's some great mess of files been deposited there being hidden
>> by the mount in normal running).

>> Basic correction technique: boot in single-user mode, in which the
>> /tmp mount will not occur, and sort the mess out from there.

>> It's possible to do this from a running system, even without unmounting
>> /tmp, but that's an exercise for the advanced student. I've described
>> how to do it before in this newsgroup, and will probably do so again
>> if given the slightest encouragement...
[...]
>It's a big problem to boot in single-user mode,
>because the system has been delivered to our customer.
>I can only inspect it by modem.
>It would be interesting to know, how I can do a correction
>without unmounting /tmp.

Right, then!

You will need root access, of course.

First, make sure nfsd is running. This will be the case if there are any
exports in /etc/dfs/dfstab. If there are none, then you may need to add
a dummy one and run "/etc/init.d/nfs.server start".

Now export the root filing system to localhost:

  share -o rw=localhost,root=localhost /

[For an initial inspection, you may prefer to use a read-only export.
A read-write one will be required for actual repair.]

Now mount it somewhere suitable:

  mount -F nfs localhost:/ /mnt

Now if you look at /mnt/tmp you are seeing the underlying mount point,
not the tmpfs filing system. You can chown it, chmod it, and get rid
of any lurking files in it.

Don't forget to "umount /mnt" and "unshare /" when you've finished.

This trick depends specifically on using NFS mounts from oneself (which
is normally deprecated, but it works). Loop-back mounts will *not*
enable you to get at the underlying /tmp.

You can also use an NFS export to another host and do the repair from
there, but that probably only adds to security worries.

Chris Thompson
Email: cet1 [at] cam.ac.uk

 
 
 

Mounting /tmp with incorrect attributes

Post by D. Roc » Wed, 25 Oct 2000 07:18:00



> [[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]

>>It's a big problem to boot in single-user mode,
>>because the system has been delivered to our customer.
>>I can only inspect it by modem.
>>It would be interesting to know, how I can do a correction
>>without unmounting /tmp.
> Well, this is rather dangerous and requires a second system:
>    share -o rw=system,root=system /
> on the "system" do:
>    mount brokensystem:/ /mnt (don't mount /tmp)
>    chmod 1777 /mnt/tmp

But there is an easier solution. The trick is: You can move mount points:

Try executing the following commands in a single command line so the
probability of a race condition is low:

# mv /tmp /tmp2; mkdir /tmp; chmod 1777 /tmp; mount -F lofs /tmp2 /tmp

Then, after the next reboot, remove the now unused /tmp2 directory.

--
Daniel

 
 
 

Mounting /tmp with incorrect attributes

Post by Chris Thomps » Wed, 25 Oct 2000 04:00:00



[...]

Quote:>But there is an easier solution. The trick is: You can move mount points:

>Try executing the following commands in a single command line so the
>probability of a race condition is low:

># mv /tmp /tmp2; mkdir /tmp; chmod 1777 /tmp; mount -F lofs /tmp2 /tmp

>Then, after the next reboot, remove the now unused /tmp2 directory.

Nice one... One can even narrow the window by:

 <... set up /tmp3 with the right owner, permissions, etc. ...>
 mount -F lofs /tmp /tmp3
 mv /tmp /tmp2 && mv /tmp3 /tmp

but of course it's still there between the two mv(1) commands. At least
this way /tmp won't exist at all in the window.

However, I have a sort of gut feeling that this is depending on unstable
parts of the specification. [Specification? What specification? ...]
It causes /etc/mnttab to get out of step with the real world, for example,
even in Solaris 8.

Chris Thompson
Email: cet1 [at] cam.ac.uk