lkml.org 
[lkml]   [2005]   [May]   [13]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RCF] [PATCH] unprivileged mount/umount
    FromMiklos Szeredi <>
    DateFri, 13 May 2005 07:47:07 +0200
    > > 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.
    
    Guess what?  It's already there.  Look in ptrace_attach() in
    kernel/ptrace.c
    
    You could argue about the usefulness of ptrace.  The point is, that
    suid/sgid programs _can_ be discerned, and ptrace _needs_ to discern
    them.
    
    And for the same reason, user controlled filesystems also need to do
    this check.  See Documentation/filesystems/fuse.txt in -mm and later
    discussion in this thread for more information.
    
    The strange thing is that people argue so vehemently about this on
    theoretical grounds.  But practice shows, that there's in fact no
    problem with it whatsoever.  This check (or something similar), has
    been in FUSE for more than 3 years, used by thousands of people, and
    it didn't cause _any_ problems, except various sub-mount related
    things, which we are trying to solve properly, by making mount
    unprivileged.
    
    Miklos
    -
    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/
    
    
    \
     
     \ /
      Last update: 2005-05-13 07:51    [from the cache]
    ©2003-2008