![]() | ||||||||||
Messages in this thread |
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 12:38 [from the cache] ©2003-2008 | ||||||||||