Date: Sat, 1 Aug 1998 13:37:40 -0400 (EDT) From: Brian Feldman <green@zone.syracuse.net> To: Terry Lambert <tlambert@primenet.com> Cc: mike@smith.net.au, freebsd-current@FreeBSD.ORG Subject: Re: flock(2) problem & fix Message-ID: <Pine.BSF.4.02.9808011334480.1346-100000@zone.baldcom.net> In-Reply-To: <199808010302.UAA06065@usr06.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I think you're right, if nothing than for the fact that it's already the
norm. This is the first time I've ever done kernel hacking, but I've
tested the patch and made a final version of it, a correction of syntax,
but it shouldn't be used because it breaks what you think it would, like
apache, which have been using flocking wrong since the very beginning. But
anyway, I'll post the correct patch, just because I don't want my
dain-bramaged code floating around ;)
Cheers,
Brian Feldman
green@unixhelp.org
--- src/sys/kern/kern_descrip.c.orig Fri Jul 31 18:28:30 1998
+++ src/sys/kern/kern_descrip.c Sat Aug 1 13:01:10 1998@@ -986,6 +986,9
@@ register struct file *fp; struct vnode *vp;
struct flock lf;+ struct stat fst;+ short gr;+
boolean_t ok = 0;
if ((unsigned)uap->fd >= fdp->fd_nfiles || (fp =
fdp->fd_ofiles[uap->fd]) == NULL)@@ -1007,10 +1010,27 @@
lf.l_type = F_RDLCK;
else return (EBADF);+ vn_stat(vp, &fst, p);+
if (uap->how & LOCK_EX && p->p_cred->pc_ucred->cr_uid != 0 &&
+ fst.st_uid != p->p_cred->pc_ucred->cr_uid &&
+ !(fst.st_mode & S_IWOTH) && !(fst.st_mode & S_IWGRP))
+ return (EPERM);
+ if (!(fst.st_mode & S_IWGRP))
+ ok = 1;
+ else {
+ for (gr = 0; gr < p->p_cred->pc_ucred->cr_ngroups; gr++)
+ if (p->p_cred->pc_ucred->cr_groups[gr - 1] == fst.st_gid)
{
+ ok = 1;
+ break;
+ }
+ }
+ if (ok) {
fp->f_flag |= FHASLOCK;
if (uap->how & LOCK_NB)
return (VOP_ADVLOCK(vp, (caddr_t)fp, F_SETLK, &lf,
F_FLOCK));
return (VOP_ADVLOCK(vp, (caddr_t)fp, F_SETLK, &lf,
F_FLOCK|F_WAIT));
+ } else
+ return (EPERM);
}
/*
On Sat, 1 Aug 1998, Terry Lambert wrote:
> > Whoops, I suppose you're right, I think I'll start testing it out =) With
> > respect to Tom's comment, this won't cnvert an exclusive to a
> > non-exclusive lock, it will return EPERM; also, the program SHOULDn't be
> > using an exclusive lock, it should be using a shared lock.
>
> What if they are using it as a semaphore, and could care less whether
> they were reading or writing the file?
>
>
> I could see a case where a program opend a file for read only to
> run an image of a program from a foreign architecture, for instance,
> and would want to use read to ensure that the "swap store" was not
> accidently corrupted by the simulator.
>
> They would want exclude modification of the image they intend only to
> *read* out from under them.
>
> In other words, they want to simulate VEXEC for a read-only mapped
> executable in user space.
>
>
>
> A secondard situation would be a set of non-work-to-do processing engines
> working on a source data set.
>
> Program one opens the file, writes new data, closes it, and signals
> program two.
>
> Program two uses the file and the output of program one to do work, and
> then requests the original program to interpolate new data bsed on its
> results, and the process repeats.
>
> Once could see this happening, for example, in a pseudo realtime data
> analysis tool that could only accept new data on soft boundries, but
> had two programs, one optimized for Fourier analysis, the other for
> Gaussian reduction (maybe the Fourier analysis program was seperate
> because it runs on a DSP and not on the main processor, and the DSP
> is not part of the acquisition channel).
>
> You could use such a system for all sorts of biometric regconitions
> (speech, speaker, retinal scanning, finger print, etc.). One could
> even envision a "frozen" back propagation neural networking program
> that had to be reset each time it was run because the outputs were
> no longer being clamped by a human giving it feedback.
>
>
> Anyway, suffice to say, I think exclusive locking a file without the
> intention *or possibility* of writing is an "ok thing to do".
>
>
> Terry Lambert
> terry@lambert.org
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.02.9808011334480.1346-100000>