Messages in this thread | | | Date | Tue, 29 Apr 2003 22:57:46 -0400 | Subject | Re: [RFD] Per-Mount UID/GID Rewrite Vector | From | Jan Harkes <> |
| |
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
- 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/
| |