mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jan Harkes <jaharkes@cs.cmu.edu>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFD] Per-Mount UID/GID Rewrite Vector
Date: Tue, 29 Apr 2003 22:57:46 -0400	[thread overview]
Message-ID: <20030430025746.GA24281@delft.aura.cs.cmu.edu> (raw)
In-Reply-To: <PEEPIDHAKMCGHDBJLHKGEEFJCJAA.rwhite@casabyte.com>

On Tue, Apr 29, 2003 at 02:42:57PM -0700, Robert White wrote:
> Opinions?  Objections?  Reasons I'm an idiot?

Working with Coda, I've thought about these issues many times. I believe
the user mapping is a many-many relationship, which is hard or even
impossible to represent with such a simple mapping. Also the mapping
would vary depending on which device/file hierarchy is inserted. For
Coda it even depends on which subtree within the filesystem you traverse
as those might access servers is different administrative organisations.

Not doing anything tricky and allowing nosuid,noexec,nodev,uid=XX,gid=XX
to apply to all filesystems (possibly within the VFS layer) is
probably a more reliable solution. Otherwise it just becomes too complex
to manage.

For Coda we're pretty much punting the uid mapping. It is used for
'presentation' purposes only as all security is based on the Coda token
and directory ACLs. We do not really use the unix owner and permission
bits. We also explicitly clear the SUID bit, and rely on a locally
installed copy of sudo or super (preferably with a modification to check
something like an SHA1 or MD5 checksum of the executable) to provide the
priviledge escalation. This way running setuid applications becomes a
local policy.

For sandboxing purposes, perhaps you could think in the direction of
mounting the device in an UML environment, or it's own namespace.

Jan


      reply	other threads:[~2003-04-30  2:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-29 21:42 Robert White
2003-04-30  2:57 ` Jan Harkes [this message]

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=20030430025746.GA24281@delft.aura.cs.cmu.edu \
    --to=jaharkes@cs.cmu.edu \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®