From owner-freebsd-current Fri Jul 31 17:05:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA28449 for freebsd-current-outgoing; Fri, 31 Jul 1998 17:05:48 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from zone.baldcom.net (zone.BALDCOM.NET [205.232.46.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA28444 for ; Fri, 31 Jul 1998 17:05:46 -0700 (PDT) (envelope-from green@zone.baldcom.net) Received: from localhost (green@localhost) by zone.baldcom.net (8.8.8/8.8.7) with SMTP id UAA25722 for ; Fri, 31 Jul 1998 20:05:19 -0400 (EDT) Date: Fri, 31 Jul 1998 20:05:19 -0400 (EDT) From: Brian Feldman To: freebsd-current@FreeBSD.ORG Subject: flock(2) problem & fix Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1425645226-901929919=:25645" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1425645226-901929919=:25645 Content-Type: TEXT/PLAIN; charset=US-ASCII Our flock(2) doesn't seem to do the right thing all the time. It seems that any user with read access to a file is allowed exclusive locking of it, which I think is wrong (does everyone agree?), and that a shared lock should be used, because the user does not own the file, and has no write permission, therefore no need for an exclusive lock. I raise the question as to whether it should matter if the lock is non-blocking or not, and that should be considered I suppose, as to assure the Right Thing will happen. Attached is a patch to sys/kern/kern_descrip.c which should fix the problem but is untested. Cheers, Brian Feldman green@unixhelp.org --- kern_descrip.c.old Fri Jul 31 18:28:30 1998 +++ kern_descrip.c Fri Jul 31 19:31:26 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((struct vnode *)fp->f_data, &fst, p); + if (uap->how & LOCK_EX && p->p_cred->pc_ucred->cr_uid != 0 && + fp->f_cred->cr_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); } /* --0-1425645226-901929919=:25645 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="flock.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="flock.diff" LS0tIGtlcm5fZGVzY3JpcC5jLm9sZAlGcmkgSnVsIDMxIDE4OjI4OjMwIDE5 OTgNCisrKyBrZXJuX2Rlc2NyaXAuYwlGcmkgSnVsIDMxIDE5OjMxOjI2IDE5 OTgNCkBAIC05ODYsNiArOTg2LDkgQEANCiAJcmVnaXN0ZXIgc3RydWN0IGZp bGUgKmZwOw0KIAlzdHJ1Y3Qgdm5vZGUgKnZwOw0KIAlzdHJ1Y3QgZmxvY2sg bGY7DQorCXN0cnVjdCBzdGF0IGZzdDsNCisJc2hvcnQgZ3I7DQorCWJvb2xl YW5fdCBvayA9IDA7DQogDQogCWlmICgodW5zaWduZWQpdWFwLT5mZCA+PSBm ZHAtPmZkX25maWxlcyB8fA0KIAkgICAgKGZwID0gZmRwLT5mZF9vZmlsZXNb dWFwLT5mZF0pID09IE5VTEwpDQpAQCAtMTAwNywxMCArMTAxMCwyNyBAQA0K IAkJbGYubF90eXBlID0gRl9SRExDSzsNCiAJZWxzZQ0KIAkJcmV0dXJuIChF QkFERik7DQorCXZuX3N0YXQoKHN0cnVjdCB2bm9kZSAqKWZwLT5mX2RhdGEs ICZmc3QsIHApOw0KKwlpZiAodWFwLT5ob3cgJiBMT0NLX0VYICYmIHAtPnBf Y3JlZC0+cGNfdWNyZWQtPmNyX3VpZCAhPSAwICYmDQorCQlmcC0+Zl9jcmVk LT5jcl91aWQgIT0gcC0+cF9jcmVkLT5wY191Y3JlZC0+Y3JfdWlkICYmDQor CQkhKGZzdC5zdF9tb2RlICYgU19JV09USCkgJiYgIShmc3Quc3RfbW9kZSAm IFNfSVdHUlApKQ0KKwkJcmV0dXJuIChFUEVSTSk7DQorCWlmICghKGZzdC5z dF9tb2RlICYgU19JV0dSUCkpDQorCQlvayA9IDE7DQorCWVsc2Ugew0KKwlm b3IgKGdyID0gMDsgZ3IgPCBwLT5wX2NyZWQtPnBjX3VjcmVkLT5jcl9uZ3Jv dXBzOyBncisrKQ0KKwkJaWYgKHAtPnBfY3JlZC0+cGNfdWNyZWQtPmNyX2dy b3Vwc1tnciAtIDFdID09IGZzdC5zdF9naWQpIHsNCisJCQlvayA9IDE7DQor CQkJYnJlYWs7DQorCQl9CQ0KKwl9DQorCWlmIChvaykgew0KIAlmcC0+Zl9m bGFnIHw9IEZIQVNMT0NLOw0KIAlpZiAodWFwLT5ob3cgJiBMT0NLX05CKQ0K IAkJcmV0dXJuIChWT1BfQURWTE9DSyh2cCwgKGNhZGRyX3QpZnAsIEZfU0VU TEssICZsZiwgRl9GTE9DSykpOw0KIAlyZXR1cm4gKFZPUF9BRFZMT0NLKHZw LCAoY2FkZHJfdClmcCwgRl9TRVRMSywgJmxmLCBGX0ZMT0NLfEZfV0FJVCkp Ow0KKwl9IGVsc2UNCisJCXJldHVybiAoRVBFUk0pOw0KIH0NCiANCiAvKg0K --0-1425645226-901929919=:25645-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message