Re: [PATCH 3/4] autofs4 - track uid and gid of last mount requestor



On Thu, 28 Feb 2008 15:22:27 +0900 Ian Kent <raven@xxxxxxxxxx> wrote:


+++ linux-2.6.25-rc2-mm1/fs/autofs4/waitq.c 2008-02-20 13:10:23.000000000 +0900
@@ -363,6 +363,38 @@ int autofs4_wait(struct autofs_sb_info *

status = wq->status;

+ /*
+ * For direct and offset mounts we need to track the requestor
+ * uid and gid in the dentry info struct. This is so it can be
+ * supplied, on request, by the misc device ioctl interface.
+ * This is needed during daemon resatart when reconnecting
+ * to existing, active, autofs mounts. The uid and gid (and
+ * related string values) may be used for macro substitution
+ * in autofs mount maps.
+ */
+ if (!status) {
+ struct dentry *de = NULL;
+
+ /* direct mount or browsable map */
+ ino = autofs4_dentry_ino(dentry);
+ if (!ino) {
+ /* If not lookup actual dentry used */
+ de = d_lookup(dentry->d_parent, &dentry->d_name);
+ ino = autofs4_dentry_ino(de);
+ }
+
+ /* Set mount requestor */
+ if (ino) {
+ if (ino) {
+ ino->uid = wq->uid;
+ ino->gid = wq->gid;
+ }
+ }
+
+ if (de)
+ dput(de);
+ }
+

But uids and gids are no longer system-wide-unique. Two different users
can have the same identifiers in different namespaces. What happens then?

That's a tricky question.

Presumably, the process requesting the mount has the user space daemon
running in the namespace within which the uid and gid are to be looked
up, by the daemon.

Am I missing something?


err, you assume more knowledge at this end about what you're trying to do
than actually exists :)

You seem to imply that if a machine is running 100 user namespaces then it
needs to run 100 mount daemons. Doesn't seem good.

What problem are you actually trying to solve here?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • Re: [autofs] [RFC] Towards a Modern Autofs
    ... >>If you want to fire up a new daemon, all that state that was supposed to ... What state is supposed to be kept in userspace that isn't? ... and neither one of us see namespaces as being worth ... That's what the Linux community is doing, ...
    (Linux-Kernel)
  • Re: [autofs] [RFC] Towards a Modern Autofs
    ... throwing out the daemon is a huge step backwards. ... >>putting additional state in userspace would be a benefit in my experience. ... No more passing pipes into the kernel or tracking the ... I'll be blunt: namespaces currently provide zero benefit ...
    (Linux-Kernel)
  • Re: [patch 2/8] allow unprivileged umount
    ... would get us a heck of a lot closer to being able to support aliasing of ... UIDs between different namespaces. ... I'd changed it to uids, ...
    (Linux-Kernel)
  • Re: [RCF] [PATCH] unprivileged mount/umount
    ... it's no more convenient than clone(). ... My use for namespaces is to simply customize the fs view on login, ... the daemon handing out namespaces... ...
    (Linux-Kernel)
  • Re: [patch 2/8] allow unprivileged umount
    ... would get us a heck of a lot closer to being able to support aliasing of ... UIDs between different namespaces. ...
    (Linux-Kernel)