Re: Change in application of default ACLs in UFS
On Wed, 6 Aug 2003, Daniel C. Sobral wrote: Note: this change contains a semantic bugfix for new file creation: we now intersect the ACL-generated mode and the cmode requested by the user process. This means permissions on newly created file objects will now be more conservative. In the future, we may want to provide alternative semantics (similar to Solaris and Linux) in which the ACL mask overrides the umask, permitting ACLs to broaden the rights beyond the requested umask. FWIW, I don't like it. This means I'll have to change my umask to o+rw for my ACLs to work correctly, since I use ACLs to _give_ rights in ways that umask cannot. I'm in the throes of implementing changes that push umask processing down into individual file systems, permitting UFS ACLs to override the umask using the ACL mask, which would reproduce the Solaris/Linux model (non-POSIX.1e). However, there are some interesting implementation question shtere, so it will probably be a bit (perhaps a couple of weeks) before I have a useful prototype worth reviewing. I agree that those semantics are useful, however :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Change in application of default ACLs in UFS
On Wed, 6 Aug 2003, Daniel C. Sobral wrote: Robert Watson wrote: Note: this change contains a semantic bugfix for new file creation: we now intersect the ACL-generated mode and the cmode requested by the user process. This means permissions on newly created file objects will now be more conservative. In the future, we may want to provide alternative semantics (similar to Solaris and Linux) in which the ACL mask overrides the umask, permitting ACLs to broaden the rights beyond the requested umask. FWIW, I don't like it. This means I'll have to change my umask to o+rw for my ACLs to work correctly, since I use ACLs to _give_ rights in ways that umask cannot. It sounds to me as if additive rights or subtractive rights should be a mount option.. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Change in application of default ACLs in UFS
Robert Watson wrote: Just an FYI to users of ACLs on UFS -- I've modified the semantics of the application of the default ACL in combination with the umask. The result is that the application of default ACLs is now more conservative than previously, so you may want to keep an eye out and make sure all the ACLs still mean what you thought they meant. I'm still exploring what the best default ACL semantics to use are -- we're now implementing POSIX.1e as spec (bitwise and). It's worth observing this is not quite the same semantics as Solaris and Linux, in which the the ACL mask overrides the umask. I have an ACL development branch in Perforce where I'm experimenting with these semantics, and will probably merge support for that prior to 5.3, probably as an option. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories -- Forwarded message -- Date: Sun, 3 Aug 2003 20:29:13 -0700 (PDT) From: Robert Watson [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/sys/ufs/ufs acl.h ufs_acl.c ufs_vnops.c rwatson 2003/08/03 20:29:13 PDT FreeBSD src repository Modified files: sys/ufs/ufs acl.h ufs_acl.c ufs_vnops.c Log: Now that the central POSIX.1e ACL code implements functions to generate the inode mode from a default ACL and creation mask, implement ufs_sync_inode_from_acl() using acl_posix1e_newfilemode(). Since ACL_OVERRIDE_MASK/ACL_PRESERVE_MASK are defined, we no longer need to explicitly pass in a preserve_mask field: this is implicit in the use of POSIX.1e semantics. Note: this change contains a semantic bugfix for new file creation: we now intersect the ACL-generated mode and the cmode requested by the user process. This means permissions on newly created file objects will now be more conservative. In the future, we may want to provide alternative semantics (similar to Solaris and Linux) in which the ACL mask overrides the umask, permitting ACLs to broaden the rights beyond the requested umask. FWIW, I don't like it. This means I'll have to change my umask to o+rw for my ACLs to work correctly, since I use ACLs to _give_ rights in ways that umask cannot. PR: 50148 Reported by:Ritz, Bruno [EMAIL PROTECTED] Obtained from: TrustedBSD Project Revision ChangesPath 1.5 +1 -2 src/sys/ufs/ufs/acl.h 1.18 +8 -78 src/sys/ufs/ufs/ufs_acl.c 1.232 +4 -8 src/sys/ufs/ufs/ufs_vnops.c ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] SYSTEM-INDEPENDENT: Works equally poorly on all systems. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Change in application of default ACLs in UFS
Just an FYI to users of ACLs on UFS -- I've modified the semantics of the application of the default ACL in combination with the umask. The result is that the application of default ACLs is now more conservative than previously, so you may want to keep an eye out and make sure all the ACLs still mean what you thought they meant. I'm still exploring what the best default ACL semantics to use are -- we're now implementing POSIX.1e as spec (bitwise and). It's worth observing this is not quite the same semantics as Solaris and Linux, in which the the ACL mask overrides the umask. I have an ACL development branch in Perforce where I'm experimenting with these semantics, and will probably merge support for that prior to 5.3, probably as an option. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories -- Forwarded message -- Date: Sun, 3 Aug 2003 20:29:13 -0700 (PDT) From: Robert Watson [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/sys/ufs/ufs acl.h ufs_acl.c ufs_vnops.c rwatson 2003/08/03 20:29:13 PDT FreeBSD src repository Modified files: sys/ufs/ufs acl.h ufs_acl.c ufs_vnops.c Log: Now that the central POSIX.1e ACL code implements functions to generate the inode mode from a default ACL and creation mask, implement ufs_sync_inode_from_acl() using acl_posix1e_newfilemode(). Since ACL_OVERRIDE_MASK/ACL_PRESERVE_MASK are defined, we no longer need to explicitly pass in a preserve_mask field: this is implicit in the use of POSIX.1e semantics. Note: this change contains a semantic bugfix for new file creation: we now intersect the ACL-generated mode and the cmode requested by the user process. This means permissions on newly created file objects will now be more conservative. In the future, we may want to provide alternative semantics (similar to Solaris and Linux) in which the ACL mask overrides the umask, permitting ACLs to broaden the rights beyond the requested umask. PR: 50148 Reported by:Ritz, Bruno [EMAIL PROTECTED] Obtained from: TrustedBSD Project Revision ChangesPath 1.5 +1 -2 src/sys/ufs/ufs/acl.h 1.18 +8 -78 src/sys/ufs/ufs/ufs_acl.c 1.232 +4 -8 src/sys/ufs/ufs/ufs_vnops.c ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
