lkml.org 
[lkml]   [1997]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.0.28: NFS caching fix did not make it
Date
Thomas Roessler wrote:
>
>
> In article <5bge7v$8et$1@miriam.fuller.edu>, Christoph Lameter wrote:
> >There was a NFS fix posted by Olaf Kirch that did not make it into 2.0.28:
> >This is very important since most locking over NFS is done this way.
>
> A propos locking - how about the flock(2) semantics which are broken in
> 2.0.27 (LOCK_EX is possible even if the locking process can't write to the
> file being locked)? I don't see any patches to the relevant parts of the
> kernel source, and this *is* a relevant issue. See also the
> denial-of-service attacks against various getties and login programs.
>
> tlr
> --
> Thomas Roessler http://home.pages.de/~roessler/
>

No! No! No! Denying LOCK_EX doesn't solve the problem, and isn't correct
BSD semantics either. You only need a LOCK_SH on wtmp to block the current
login/getty implementations indefinitely anyway. login & getty should be
fixed. flock() isn't broken the way it is.

- if login/getty are to lock the wtmp file at all, they should do so
with fcntl()/lockf(), which already have the semantics you're asking
for.

- even this won't help, because a F_RDLCK on wtmp will block login/getty's
F_WRLCK.

- login/getty don't need to lock the wtmp file anyway, they can just open
it with O_WRONLY|O_APPEND. This is what SunOS 4.1.x and BSD do. I'm just
about to check what Solaris does (gotta compile strace first).

-Andy

--
Andy Walker Kvaerner Engineering a.s.
Andrew.Walker@lysaker.kvaerner.no P.O. Box 222, N-1324 Lysaker, Norway

......if the answer isn't violence, neither is your silence......

(pwei barmy army - oslo "filial")

\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.044 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site