From owner-freebsd-current@FreeBSD.ORG Fri Feb 19 23:23:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E74F0106568B; Fri, 19 Feb 2010 23:23:30 +0000 (UTC) (envelope-from alexz@visp.ru) Received: from mail.visp.ru (srv1.visp.ru [91.215.204.2]) by mx1.freebsd.org (Postfix) with ESMTP id 98F4C8FC13; Fri, 19 Feb 2010 23:23:29 +0000 (UTC) Received: from 91-215-205-255.static.visp.ru ([91.215.205.255] helo=zagrebin) by mail.visp.ru with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1NicC0-000ND4-Kf; Sat, 20 Feb 2010 02:23:28 +0300 From: "Alexander Zagrebin" To: Date: Sat, 20 Feb 2010 02:23:28 +0300 Message-ID: <3A28259E0677447BBFDECFCCDBD97FD5@vosz.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0D69_01CAB1D3.B0549730" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcqxuorLM1sfy3w2QYqffH6AzsTGsQ== Cc: freebsd-current@freebsd.org Subject: ZFS allows deletion of files in a sticky directory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 23:23:31 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0D69_01CAB1D3.B0549730 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit I have found that directory entry may be deleted from a ZFS directory with the sticky bit, if "the entry is a plain file and you have write access" (this is citation from a comments in zfs_dir.c) But this behavior isn't described in the sticky(8) and isn't allowed on a UFS. The attached patch provides the UFS-like behavior of a sticky directories on a ZFS. Is this bug or feature? -- Alexander Zagrebin ------=_NextPart_000_0D69_01CAB1D3.B0549730 Content-Type: application/octet-stream; name="patch-zfs_dir.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="patch-zfs_dir.c" --- = /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c.orig = 2009-07-20 23:16:42.000000000 +0400=0A= +++ /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c = 2010-02-20 01:23:45.112613715 +0300=0A= @@ -962,7 +962,6 @@=0A= *=0A= * you own the directory,=0A= * you own the entry,=0A= - * the entry is a plain file and you have write access,=0A= * or you are privileged (checked in secpolicy...).=0A= *=0A= * The function returns 0 if remove access is granted.=0A= @@ -984,9 +983,7 @@=0A= downer =3D zfs_fuid_map_id(zfsvfs, zdp->z_phys->zp_uid, cr, ZFS_OWNER);=0A= fowner =3D zfs_fuid_map_id(zfsvfs, zp->z_phys->zp_uid, cr, ZFS_OWNER);=0A= =0A= - if ((uid =3D crgetuid(cr)) =3D=3D downer || uid =3D=3D fowner ||=0A= - (ZTOV(zp)->v_type =3D=3D VREG &&=0A= - zfs_zaccess(zp, ACE_WRITE_DATA, 0, B_FALSE, cr) =3D=3D 0))=0A= + if ((uid =3D crgetuid(cr)) =3D=3D downer || uid =3D=3D fowner)=0A= return (0);=0A= else=0A= return (secpolicy_vnode_remove(ZTOV(zp), cr));=0A= ------=_NextPart_000_0D69_01CAB1D3.B0549730--