Re: DoS with POSIX file locks?

* Miklos Szeredi (miklos@xxxxxxxxxx) 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Global Lock-Free Proxy Collector Anchor Scheme...
    ... lock your_collection->lock ... unlock your_collection->lock ... Step 7 can't rise above step 6 ... But afaik POSIX doesn't guarantee that other threads (that don't use ...
    (comp.programming.threads)
  • Re: Global Lock-Free Proxy Collector Anchor Scheme...
    ... lock your_collection->lock ... make new node visible to readers ... unlock your_collection->lock ... But afaik POSIX doesn't guarantee that other threads (that don't use ...
    (comp.programming.threads)
  • Re: thread mutexes
    ... I would like, if possible, someone to explain to me POSIX threads? ... In particular, the mutex lock/unlock functions. ... exactly they lock. ... You as the programmer establish a convention: ...
    (comp.unix.programmer)
  • Re: [PATCH] AFS: Implement file locking
    ... Don't the POSIX and flock lock-handling routines in the ... write lock on an inode (because somebody else already holds a read lock ... Neither posix nor flock locks delay a lock because of pending ...
    (Linux-Kernel)
  • Re: Module imports during object instantiation
    ... Bruno Desthuilliers wrote: ... if lock is None or lock!= 1: ... On Linux: posix ... Then pass the module to the initializer. ...
    (comp.lang.python)