mirror of
https://git.FreeBSD.org/src.git
synced 2024-12-13 10:02:38 +00:00
o Althought this is not specified in POSIX.1e, the UFS ACL implementation
coerces the deletion of a default ACL on a directory when no default ACL EA is present to success. Because the UFS EA implementation doesn't disinguish the EA failure modes "that EA name has not been administratively enabled" from "that EA name has no defined data", there's a potential conflict in error return values. Normally, the lack of administratively configured EA support is coerced to EOPNOTSUPP to indicate that ACLs are not available; in this case, it is possible to get a successful return, even if ACLs are not available because EA support for them has not been enabled. Expand the comment in ufs_setacl() to identify this case. Obtained from: TrustedBSD Project
This commit is contained in:
parent
ac8b3dd7dc
commit
b6e0472987
Notes:
svn2git
2020-12-20 02:59:44 +00:00
svn path=/head/; revision=85581
@ -417,9 +417,14 @@ ufs_setacl(ap)
|
||||
* Attempting to delete a non-present default ACL
|
||||
* will return success for portability purposes.
|
||||
* (TRIX)
|
||||
*
|
||||
* XXX: Note that since we can't distinguish
|
||||
* "that EA is not supported" from "that EA is not
|
||||
* defined", the success case here overlaps the
|
||||
* the ENOENT->EOPNOTSUPP case below.
|
||||
*/
|
||||
/* XXX: the ENOENT here will eventually be ENOATTR. */
|
||||
if (error == EINVAL)
|
||||
if (error == ENOENT)
|
||||
error = 0;
|
||||
} else
|
||||
error = vn_extattr_set(ap->a_vp, IO_NODELOCKED,
|
||||
|
Loading…
Reference in New Issue
Block a user