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

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

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

Jim Carter wrote:

>On Fri, 9 Jan 2004, Mike Waychison wrote:
>
>  
>
>>Jim Carter wrote:
>>    
>>
>>>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.
>>    
>>
>
>There are 2 inodes here: the mount point (owned by autofs) and what's
>mounted on it.  We mustn't monkey with the mountee's data, of course.  I'm
>talking about statting the mount point itself.  You can't do that by name,
>but in a prior discussion we were talking about opening the mount point
>before the mount, and later doing fstat on the file descriptor.  HPA
>mentioned providing a readlink method and doing lstat on the mount point by
>name, which would intercept the path walk before the mountee was noticed.
>
>So the caller gets the mode of the mount point, which autofs can create or
>interpret any way it wants, rather than the mountee's data.
>
>  
>
Ok.  Then the kernel would need to periodically make these checks..   It 
could work, but I see it as yet another communication kludge.

>>>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.
>>    
>>
>
>Agreed, you wonder if the right processes are going to be picked.  But...
>"Ask for the moon; they might give it to you."  In the present case it
>should be possible to stick the fuser execution into the autofs shutdown
>script -- it already is aware that unmounts haven't finished, and it
>probably knows or can find out which filesystems are involved.
>
>  
>
This probably isn't best placed in the initscript.  The automount daemon 
should instead have a timeout setup for unmounting these filesystems.  
If the unmount hangs for more than x seconds, move on to the next one.   
Let init take care of killing off processes if they haven't died in time 
for shutdown. 

-- 
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