Messages in this thread | | | Subject | Re: [RCF] [PATCH] unprivileged mount/umount | From | Bryan Henderson <> | Date | Thu, 12 May 2005 14:08:21 -0700 |
| |
> So if a user creates a private namespace, it should have the choice of: > > 1) Giving up all suid rights (i.e. all mounts are cloned and > propagated with nosuid) > > 2) Not giving up suid for cloned and propagated mounts, but having > extra limitations (suid/sgid programs cannot access unprivileged > "synthetic" mounts)
(2) isn't realistic. There's no such thing as a suid program. Suid is a characteristic of a _file_. There's no way to know whether a given executing program is running with privileges that came from a suid file getting exec'ed. Bear in mind that that exec could be pretty remote -- done by a now-dead ancestor with three more execs in between.
Many user space programs contain hacks to try to discern this information, and they often cause me headaches and I have to fix them. The usual hacks are euid==uid, euid==suid, and/or euid==0. It would be an order of magnitude worse for the kernel to contain such a hack.
-- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems - 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/
| |