[lkml]   [2005]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RCF] [PATCH] unprivileged mount/umount
    > 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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-05-12 23:13    [W:0.021 / U:0.208 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site