lkml.org 
[lkml]   [2006]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: DoS with POSIX file locks?
* Miklos Szeredi (miklos@szeredi.hu) wrote:
> > > Apps using LinuxThreads seem to be candidates:
> > >
> > > According to POSIX 1003.1c, a successful `exec*' in one of the
> > > threads should automatically terminate all other threads in the
> > > program. This behavior is not yet implemented in LinuxThreads.
> > > Calling `pthread_kill_other_threads_np' before `exec*' achieves
> > > much of the same behavior, except that if `exec*' ultimately
> > > fails, then all other threads are already killed.
> > >
> > > steal_locks() was probably added as a workaround for this case, no?
> >
> > Possibly, but LinuxThreads were never really POSIX thread compliant
> > anyway. Anyhow, the problem isn't really LinuxThreads, it is rather that
> > the existence of the standalone CLONE_FILES flag allows you to do a lot
> > of weird inheritance crap with 'posix locks' that the POSIX standards
> > committees never even had to consider.
>
> Yes. The execve-with-multiple-threads/posix-locks interaction is not
> documented for LinuxThreads but removing steal_locks() makes that
> implementation slighly differently incompatible to POSIX. Some
> application _might_ be relying on the current behavior.
>
> It's just a question of how much confidence do we have, that no app
> will break if steal_locks() is removed. This function was added by
> Chris Wright on 2003-12-29 (Cset 1.1371.111.3):
>
> Add steal_locks helper for use in conjunction with unshare_files to
> make sure POSIX file lock semantics aren't broken due to
> unshare_files.
>
> Chris, do you remember if this was due to some concrete breakage or
> just a preemtive measure?

Concrete breakage. Something like:

clone(CLONE_FILES)
/* in child */
lock
execve
lock

w/out the kludge[1], the lock fails. I should have a test program about
that I wrote to test this, although it was originally triggered via some
LTP or LSB type of test (don't recall which).

thanks,
-chris

[1] happy to see it go. i concur with Trond, there's no sane way to get
rid of it w/out formalizing CLONE_FILES and locks on exec
-
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: 2006-03-21 20:19    [W:0.282 / U:0.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site