From: Christoph Hellwig <hch@infradead.org>
To: Steve French <smfrench@austin.rr.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cifs: handle termination of cifs oplockd kernel thread
Date: Fri, 29 Apr 2005 22:31:08 +0100 [thread overview]
Message-ID: <20050429213108.GA15262@infradead.org> (raw)
In-Reply-To: <4272A275.4030801@austin.rr.com>
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.
next prev parent reply other threads:[~2005-04-29 21:37 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-29 21:09 [PATCH] cifs: handle termination of cifs oplockd kernel thread Steve French
2005-04-29 21:31 ` Christoph Hellwig [this message]
2005-04-29 22:20 ` Steve French
2005-05-11 8:56 ` Christoph Hellwig
2005-05-11 18:19 ` Steve French
2005-05-16 9:34 ` Christoph Hellwig
[not found] <3YLdQ-4vS-15@gated-at.bofh.it>
2005-04-29 23:18 ` Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>
2005-04-30 7:32 ` Christoph Hellwig
2005-04-30 8:14 ` Miklos Szeredi
2005-04-30 8:29 ` Christoph Hellwig
2005-04-30 9:22 ` Miklos Szeredi
2005-04-30 10:57 ` Miklos Szeredi
2005-04-30 13:28 ` Steve French
2005-04-30 14:53 ` J. Bruce Fields
2005-04-30 14:50 ` Steve French
2005-04-30 17:23 ` Miklos Szeredi
2005-04-30 16:16 ` Miklos Szeredi
2005-04-30 15:27 ` Steve French
2005-05-01 0:10 ` Bodo Eggert
2005-05-11 8:59 ` Christoph Hellwig
2005-04-30 12:52 ` Steve French
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050429213108.GA15262@infradead.org \
--to=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=smfrench@austin.rr.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox