Re: dot-locking
>>>>> "Chris" == Chris Fearnley <cjf@netaxs.com> writes:
Chris> 'Karl M. Hegbloom wrote:'
>> 'lckpwd', the password locking routine in libc, is an
>> interesting function. It does not perform the link, and
>> therefore would not be 'nfs' safe. I don't think it needs to
>> be though, on most systems, does it? A 'transnames' patched
>> system may well need 'nfs' safe /etc/passwd locking. There is
>> a 'pragma weak' on the 'lckpwd' functions... I think this
>> means that a LD_PRELOAD is allowed to replace it, is that
>> right?
Chris> I would very much like to NFS mount /etc/security (is that
Chris> what the shadow passwd suite uses?). So I'd call it a bug
Chris> (ahem, limitation) in libc.
The limitation is in Linux. A lockfile is a kluge; the Right Way is
to put a SYSVr4 style l_sysid field into 'struct flock' (see:
<asm/fcntl.h>) and support it inside the kernel, isn't it? It would
seem to me that this will 'happen' eventually; mandatory locks are in
now, so nfs clean 'fcntl' locking can't be too far off.
Q: Many programs will need to be recompiled if this change is made,
right? (Since the size of the flock structure will change by
+sizeof(long).)
I think it would be simple to take the locking code fragment out of
publib/lockfile/lockfile.c and plug it into the libc5-5.4.23 __lckpwd
function, or maybe better, into a clone of it compiled into a separate
.so file.
I think that this lib could then be linked into a program when it's
built, which would use that version rather than the one in libc. I've
never tried this; but it seems possible. It could also be utilized by
an existing program with a LD_PRELOAD environment setting, I believe.
To do this, one would need to ftp 'publib' and the 'libc' sources
from a Debian mirror and read the relavant code, then make the
library.
Karl M. Hegbloom <karlheg@inetarena.com>
http://www.inetarena.com/~karlheg
Portland, OR USA
Debian GNU 1.2 Linux 2.0.29t
Reply to: