Re: [PATCH] cifs: handle termination of cifs oplockd kernel thread

From: Miklos Szeredi (miklos_at_szeredi.hu)
Date: 04/30/05

  • Next message: Miklos Szeredi: "Re: [PATCH] private mounts" 
    To: hch@infradead.org
Date:	Sat, 30 Apr 2005 11:22:48 +0200

    > >
    > > - global limit on user mounts
    >
    > I don't think we need that one.

    We have that for open files '/proc/sys/fs/file-max'. It limits the
    total memory usage of the thing. Which otherwise is hard if you have
    a system with lots of users.

    > > - possibly per user limit on mounts
    >
    > Makes sense as an ulimit, that way the sysadmin can easily disable the
    > user mount feature aswell.
    >
    > > - acceptable mountpoints (unlimited writablity is probably a good minimum)
    >
    > Yupp.
    >
    > > - acceptable mount options (nosuid, nodev are obviously not)
    >
    > noexecis a bit too much, so the above look good.
    >
    > > - filesystems "safe" to mount by users
    >
    > what filesystem do you think is unsafe?
    >
    > - virtual filesystems exporting kernel data are obviously safe as
    > they enforce permissions no matter who mounted them. (actually we'd
    > need to check for some odd mount options)

    Maybe sysadmin doesn't want to let users see /sys for example. How
    would you disable it if users can mount it themselfes? OK, you can
    disable user mounts completely, but that's probably not fine grained
    enough for some.

    > - block-based filesystems should be safe as long as the mounter has
    > access to the underlying block device

    Not true if user controls the baking device (e.g. loopback). Most
    block based filesystems are probably unsafe at the moment, because not
    enough consistency checking is done at runtime. Are things like
    non-cyclic directory graphs ensured by all filesystems? My guess is
    not. See also Linus' comment about the state of the iso9660
    filesystem:

      http://lwn.net/Articles/128744/

    > - network/userspace filesystems should be fine aswell

    They should, but again I wonder if NFS with all it's complexity is
    being careful enough with what it accepts from the server.

    Smbfs might be close to safe, since it's already available for users
    to mount from an arbitrary server.

    So safeness is a per-filesystem property, determined, how well it
    checks input.

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

  • Next message: Miklos Szeredi: "Re: [PATCH] private mounts"

    Relevant Pages

    • Will this work in 6.0?
      ... Verify that the system supports two hard drives. ... Boot to single user mode: ... # mount -a -t ufs ... If the new filesystems aren't automatically mounted, ...
      (comp.unix.bsd.freebsd.misc)
    • NLS for HFS and "mount" tool.
      ... Also i would like to ask someone who is responsible for "mount" tool. ... the same device and mount points but different filesystems and options. ... This would greatly improve handling of removable devices. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: udev and automounting
      ... This package automatically mounts USB mass ... and unmounts them when they are ... Does this limit filesystems to FAT? ... maybe mount with sync instead of async, ...
      (Debian-User)
    • Re: -mm -> 2.6.13 merge status (fuse)
      ... allow users to be able to mount FUSE filesystems. ... Root squash in NFS has similar effect. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Mount information during boot.
      ... only comments and filesystems that I want mounted - see ... Wed Jan 31 18:52:45 2007: Done activating swap. ... I took a look at that script and there is a bunch of mount stuff going ...
      (Debian-User)