low-end persistence strategies?

John Lenton john at grulic.org.ar
Fri Feb 18 11:35:28 EST 2005


On Fri, Feb 18, 2005 at 07:57:21AM -0800, Michele Simionato wrote:
> Uhm ... I reading /usr/src/linux-2.4.27/Documentation/mandatory.txt
> The last section says:
> 
> """
> 6. Warning!
> -----------
> 
> Not even root can override a mandatory lock, so runaway processes
> can wreak havoc if they lock crucial files. The way around it is to
> change the file permissions (remove the setgid bit) before trying to
> read or write to it.  Of course, that might be a bit tricky if the
> system is hung :-(
> """
> 
> so lockf locks do not look completely harmless ...

if you read the whole file, you will have read that turning on
mandatory locks is not trivial. I never said it was harmless, and in
fact (as that section explains) it's a bad idea for most cases; there
are some (very few) situations where you need it, however, and so you
can get at that functionality. Having to mount your filesystem with
special options and twiddling the permission bits is a pretty strong
hint that the implementors didn't think it was a good idea for most
cases, too.

Hmm, just read that file, and it doesn't mention the "have to mount
with special options" bit. But if you look in mount(8), you see an
entry under the options list,

   mand   Allow mandatory locks on this filesystem. See fcntl(2)

and if you look in fcntl(2), you see that

   Mandatory locking
       (Non‐POSIX.)  The above record locks may be either advi‐
       sory or mandatory, and are advisory by default.  To make
       use  of  mandatory  locks,  mandatory  locking  must  be
       enabled (using the "‐o mand" option to mount(8)) for the
       file system containing the file to be locked and enabled
       on the file itself (by disabling group  execute  permis‐
       sion  on  the  file  and enabling the set‐GID permission
       bit).

       Advisory locks are not  enforced  and  are  useful  only
       between   cooperating  processes.  Mandatory  locks  are
       enforced for all processes.

if I have come across as recommending mandatory locks in this thread,
I apologize, as it was never my intention. It is a cool feature for
the .001% of the time when you need it (and the case in discussion in
this thread is not one of those), but other than that it's a very,
very bad idea. In the same league of badness as SysV IPC; I'd still
mention SysV IPC to someone who asked about IPC on Linux, however,
because there are places where it is useful even though most times
it's a stupid way to do things (yes, Oracle, *especially* you).

-- 
John Lenton (john at grulic.org.ar) -- Random fortune:
A pencil with no point needs no eraser.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20050218/7cda369a/attachment.sig>


More information about the Python-list mailing list