Messages in this thread | | | Date | Fri, 29 Apr 2005 22:31:08 +0100 | From | Christoph Hellwig <> | Subject | Re: [PATCH] cifs: handle termination of cifs oplockd kernel thread |
| |
On Fri, Apr 29, 2005 at 04:09:09PM -0500, Steve French wrote: > > does and who revied that? Things like that don't have a business in the > > kernel, and certainly not as ioctl. > > Other filesystems such as smbfs had an ioctl that returned the uid of > the mounter which they used (in the smbfs case in smbumount). This was > required by the unmount helper to determine if the unmount would allow a > user to unmount a particular mount that they mounted. Unlike in the > case of mount, for unmount you can not use the owner uid of the mount > target to tell who mounted that mount. I had not received any better > suggestions as to how to address it. I had proposed various > alternatives - exporting in in /proc/mounts e.g.
exporting the uid using the show_options superblock methods sounds like a much better option.
> As we try to gradually obsolete smbfs, this came up with various users > (there was even a bugzilla bug opened for adding it) who said that they > need the ability to unmount their own mounts for network filesystems > without using /etc/fstab. Unfortunately for network filesytsems, > unlike local filesystems, it is impractical to put every possible mount > target in /etc/fstab since servers get renamed and the universe of > possible cifs mount targets for a user is large.
Do you use the same suid wrapper hack for mounts as fuse? Maybe you should chime in on that thread so we can find a proper solution.
> > There seemed only three alternatives - > 1) mimic the smbfs ioctl - as can be seen from smbfs and smbumount > source this has portability problems because apparently there is no > guarantee that uid_t is the same size in kernel and in userspace - smbfs > actually has two ioctls for different sizes of uid field - this seemed > like a bad idea > 2) export the uid in /proc/mounts - same problem as above
No. /proc/self/mounts is an ASCII format, so there's no problem with differemt sizes.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |