Re: [PATCH] capabilites, take 2

From: Olaf Dietsche (olaf+list.linux-kernel_at_olafdietsche.de)
Date: 05/14/04

  • Next message: Chris Wright: "Re: [PATCH] capabilities, take 3 (Re: [PATCH] capabilites, take 2)" 
    To: Valdis.Kletnieks@vt.edu
Date:	Fri, 14 May 2004 07:33:32 +0200

    Valdis.Kletnieks@vt.edu writes:

    > On Thu, 13 May 2004 18:20:10 PDT, Chris Wright said:
    >
    >> I think it still needs more work. Default behavoiur is changed, like
    >> Inheritble is full rather than clear, setpcap is enabled, etc. Also,
    >> why do you change from Posix the way exec() updates capabilities? Sure,
    >> there is no filesystem bits present, so this changes the calculation,
    >> but I'm not convinced it's as secure this way. At least with newcaps=0.
    >
    > The last time the "capabilities" thread reared its head a while ago, Andy made
    > a posting that pretty conclusively showed that the Posix way was totally b0rken
    > if you ever intended to support filesystem bits. So if you wanted to ever have
    > a snowball's chance of supporting something like:
    >
    > chcap cap_net_raw+ep /bin/ping

    Seems like you're not aware of:
    <http://www.olafdietsche.de/linux/capability/>

    This supports filesystem capabilities with the current (POSIX?)
    implementation. So, whatever Andy has shown, it has at least one
    counter evidence q.e.d.

    > 2) Toss all the filesystems capabilities support out the window.

    I agree to disagree ;-)

    Regards, Olaf.
    -
    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: Chris Wright: "Re: [PATCH] capabilities, take 3 (Re: [PATCH] capabilites, take 2)"

    Relevant Pages

    • Re: [PATCH] capabilites, take 2
      ... >> Inheritble is full rather than clear, setpcap is enabled, etc. ... > a posting that pretty conclusively showed that the Posix way was totally b0rken ... > if you ever intended to support filesystem bits. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: -mm -> 2.6.13 merge status
      ... >> mean that the success rate for crashing kernels is not high enough for ... > other crashdump methods. ... This is not a filesystem but a filesystem + ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: silent semantic changes with reiser4
      ... > Marketed product: a set of hooks, the wider the better, no matter how ... remove these features and make it a "normal" filesystem. ... you changed into a meta directory using ftp and some manage to break ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: silent semantic changes with reiser4
      ... on a sufficiently fast box; don't work when there are ... Remember that the Solaris attribute model is just another filesystem ... inodes that delete themselves when other inodes are changed creep me ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Mutiple filename changes
      ... filesystem, it can apply its own rules on it. ... its FAT driver code, and this code is - due to the very nature of FAT ... No, but POSIX uses such structures, and so the Linux virtual filesystem ... FAT/FAT32, eventhough the virtual filesystem layer does show an owner, ...
      (comp.os.linux.setup)