Re: [patch] buffer overflow, failure to auto-dismount, log file diarrhea

[Mike Waychison <Michael.Waychison@Sun.COM>]

[-- Attachment #1.1: Type: text/plain, Size: 4555 bytes --]

Jim Carter wrote:

>On Sat, 3 Jan 2004, Ian Kent wrote:
>  
>
>>On Fri, 2 Jan 2004, Jim Carter wrote:
>>    
>>
>>>Right, expire.c :: autofs4_expire() bypasses a mount point if its last_used
>>>field is too recent, and then it checks is_tree_busy().  Oh, look, a kludge
>>>that could be added, how wonderful!  Assuming that it's feasible to get
>>>module-provided data into the inode data returned from sys_stat or
>>>sys_fstat, a mode bit could be set to indicate busyness, e.g. user write
>>>implies not busy.
>>>      
>>>
>>A user write implies an open file. The expire routine must identify this
>>dentry as busy or it's a bug that needs to be fixed.
>>    
>>
>
>No, I meant that when the sys_stat method fills in the mode field of
>the returning stat structure, it would be reported as 555 for a busy
>filesystem, or 755 if it looks idle and dismountable.  The mode field as
>seen by the VFS layer can stay at 755.  This would be when statting
>autofs's directory inode, not whatever is mounted on it.
>
>  
>
This hijacking of the st_mode is just that, hijacking.  You'd be 
changing the mode of the directory on the NFS filesystem..  This 
wouldn't work well in the VFS when it tries to check permissions, but it 
also wouldn't work for more than one NFS client accessing the same 
filehandle.

>Is it really true that the VFS layer doesn't maintain use counts for
>directories where you can find them easily?
>
>  
>
Use counts for directories?  The of a file has no real consistent 
corelation with which directory that file belongs.

>>>So the key task is to bulldoze aside the wreckage so a new instance of the
>>>revitalized NFS server can be mounted.  Killing the moribund processes and
>>>forcibly dismounting the destroyed filesystem instance are important so as
>>>to recover resources, but the client can continue to function for quite a
>>>long time even if that's not done; the only totally vital action is to be
>>>able to remount, and that can possibly be done by renaming, or by
>>>remounting the wreckage elsewhere, deferring the actual dismount.
>>>      
>>>
>>I'll have to think about this for a while. The rename idea might cause all
>>sorts of problems.
>>    
>>
>
>I can imagine.  Maybe a -move remount?  Can you even do this when the
>mounted FS is busy?  Well...
>
>mkdir mtpt1 ; mkdir mtpt2
>mount -t nfs hollyfs:/m1 mtpt1
>cd mtpt1
>sleep 3600 &		(PID is 2486)
>cd ..
>umount mtpt1		(device is busy -- correct)
>mount --move mtpt1 mtpt2	(works -- yay!)
>ls -l /proc/2486/cwd	(says: /proc/2486/cwd -> /tmp/root.jimc/mtpt2/)
>grep mtpt /proc/mounts	(says: hollyfs:/m1 /tmp/root.jimc/mtpt2 nfs...)
>grep mtpt /etc/mtab	(says: hollyfs:/m1 /tmp/root.jimc/mtpt1 nfs...
>			/tmp/root.jimc/mtpt1 /tmp/root.jimc/mtpt2 none rw 0 0
>kill 2486
>umount mtpt2		(works -- correct)
>grep mtpt /proc/mounts	(says: nothing)
>grep mtpt /etc/mtab	(says: hollyfs:/m1 /tmp/root.jimc/mtpt1, hiss, boo)
>
>So you can do a move mount on a busy filesystem; the only downside is that
>/etc/mtab has a stale entry in it -- obviously a bug, not an essential
>behavior.
>
>  
>
Yup, it's a bug, however now that you can mount two filesystems on top 
of each other, there really is no reliable way to know which entry in 
/etc/mtab has moved.  Eg:

# mkdir /foo
# mount -o ro host:/path /foo
# mount -o rw host:/path /foo
# cat /etc/mtab
(two lines for /foo are printed)
# mkdir /bar
# mount --move /foo /bar

Which entry in /etc/mtab is changed from /foo to /bar?  Unless you can 
make steadfast rules on entry ordering, you can't reliably decide which 
entry has changed.

Even worse, /etc/mtab is broken when using multiple namespaces.

>>A kill -9 on the blocked process needs further investigation. I'm not sure
>>what the situation is there (probably not good).
>>    
>>
>
>I would really like it if, when autofs decided to forcibly unmount, it
>could kill the using processes, as in "fuser -k -m /net/host/mountpoint".
>Actually this is a general issue for unmount(8), not specific to autofs.
>But one wonders whether fuser is going to run wild...
>
>  
>
Like HPA already mentioned, this is bad.  I don't even think you could 
reliably detect this.

-- 
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
mailto: Michael.Waychison@Sun.COM
http://www.sun.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me, 
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 


[-- Attachment #1.2: Type: application/pgp-signature, Size: 251 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs