From owner-p4-projects@FreeBSD.ORG Tue Jul 5 12:02:13 2005 Return-Path: X-Original-To: p4-projects@freebsd.org Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 677DA16A420; Tue, 5 Jul 2005 12:02:13 +0000 (GMT) X-Original-To: perforce@freebsd.org Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FC9716A41C for ; Tue, 5 Jul 2005 12:02:13 +0000 (GMT) (envelope-from bb+lists.freebsd.perforce@cyrus.watson.org) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1086443D49 for ; Tue, 5 Jul 2005 12:02:13 +0000 (GMT) (envelope-from bb+lists.freebsd.perforce@cyrus.watson.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.1/8.13.1) with ESMTP id j65C2CcX076909 for ; Tue, 5 Jul 2005 12:02:12 GMT (envelope-from bb+lists.freebsd.perforce@cyrus.watson.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.13.1/8.13.1/Submit) id j65C2C9M076906 for perforce@freebsd.org; Tue, 5 Jul 2005 12:02:12 GMT (envelope-from bb+lists.freebsd.perforce@cyrus.watson.org) Date: Tue, 5 Jul 2005 12:02:12 GMT Message-Id: <200507051202.j65C2C9M076906@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to bb+lists.freebsd.perforce@cyrus.watson.org using -f From: Robert Watson To: Perforce Change Reviews Cc: Subject: PERFORCE change 79601 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2005 12:02:14 -0000 http://perforce.freebsd.org/chv.cgi?CH=79601 Change 79601 by rwatson@rwatson_paprika on 2005/07/05 12:01:24 Annotate some uses of suser() in file system code that will need more attention. In reiserfs, the use of suser appears deffective. In UFS, it requires some inspection of POSIX.1e to figure out how to use capabilities. Affected files ... .. //depot/projects/trustedbsd/sebsd/sys/gnu/reiserfs/reiserfs_vfsops.c#2 edit .. //depot/projects/trustedbsd/sebsd/sys/ufs/ffs/ffs_vnops.c#11 edit Differences ... ==== //depot/projects/trustedbsd/sebsd/sys/gnu/reiserfs/reiserfs_vfsops.c#2 (text+ko) ==== @@ -125,8 +125,15 @@ return (error); } - /* If mount by non-root, then verify that user has necessary - * permissions on the device. */ + /* + * If mount by non-root, then verify that user has necessary + * permissions on the device. + * + * XXXRW: Probably, should check if the user has access, then + * exercise appropriate privilege to override the protections if + * desired. Question: why are we not simply relying on the results + * of VOP_ACCESS()? + */ if (suser(td)) { accessmode = VREAD; if ((mp->mnt_flag & MNT_RDONLY) == 0) ==== //depot/projects/trustedbsd/sebsd/sys/ufs/ffs/ffs_vnops.c#11 (text+ko) ==== @@ -731,6 +731,9 @@ * If we successfully wrote any data, and we are not the superuser * we clear the setuid and setgid bits as a precaution against * tampering. + * + * XXXRW: What should this be in the world of capabilities? Possibly + * CAP_SETUID and CAP_SETGID? */ if (resid > uio->uio_resid && ap->a_cred && suser_cred(ap->a_cred, SUSER_ALLOWJAIL)) { @@ -1056,6 +1059,9 @@ * If we successfully wrote any data, and we are not the superuser * we clear the setuid and setgid bits as a precaution against * tampering. + * + * XXXRW: What should this be in the world of capabilities? Possibly + * CAP_SETUID and CAP_SETGID? */ if (resid > uio->uio_resid && ucred && suser_cred(ucred, SUSER_ALLOWJAIL)) {