On Tue, Mar 19, 2002 at 01:34:12AM +0100, Russell Coker wrote:
> open("/var/run/utmp", O_RDWR) = -1 EACCES (Permission denied)
> open("/var/run/utmp", O_RDONLY) = 4
> fcntl64(4, F_GETFD) = 0
> fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
> _llseek(4, 0, [0], SEEK_SET) = 0
> alarm(0) = 0
> rt_sigaction(SIGALRM, {0x4013dc10, [], 0x4000000}, {SIG_DFL}, 8) = 0
> alarm(1) = 0
> fcntl64(4, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
> The above is a short strace of kcheckpass (the password checking program used
> by the KDE screen blank program).
> It uses pam to check the password for the user who runs it, the code in
> question is all in pam (the kde code doesn't seem to have any getutent() type
> functions or any direct file access). Which is why I'm asking here as
> tracing through the pam code to find the answer could be a lot of work.
> I need to know why it wants to lock a range of length 0. Is this a bug or is
> there some good reason for it?
It's a read lock, isn't it? In which case, does it really matter how
many bytes it's locking? (Unless, perhaps, requesting a read lock on
more bytes than the file actually has causes a failure, in which case
'0' is the only guaranteed safe value?)
If the question is really "why does it want a read lock at all?", I
don't think I have an answer for that one.
Steve Langasek
postmodern programmer
Attachment:
pgpNAM3T3fW2t.pgp
Description: PGP signature