> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
