Date: Thu, 5 Dec 2002 10:49:28 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: kai ouyang <oykai@msn.com> Cc: Current@FreeBSD.org Subject: Re: setfacl requirements? Message-ID: <Pine.NEB.3.96L.1021205104032.70896G-100000@fledge.watson.org> In-Reply-To: <F25Huczmox8GM8jAUG60003622c@hotmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 5 Dec 2002, kai ouyang wrote:
> Hi, everybody,
> >From Robert N M Watson
> >(1) UFS_ACL isn't enabled
> Yes, I am sure that in my kernel config:
> options UFS_ACL
> options UFS_EXTATTR
> options UFS_EXTATTR_AUTOSTART
Ok, looks good.
> >(2) Extended attributes aren't available on the file system (shouldn't
> > happen for UFS2, but might happen for UFS1 if you don't have
> > UFS_EXTATTR and appropriate configuration of EAs)
> I do as the "README.alcs"
> mkdir -p /usr/.attribute/system
> cd /.attribute/system
> extattrctl initattr -p /usr/ 388 posix1e.acl_access
> extattrctl initattr -p /usr/ 388 posix1e.acl_default
Followed by a reboot, right?
> >(3) The file system isn't mounted with the ACL option: either -o acls (or
> > acls in the fstab file), or more reliably, setting the "tunefs -a
> > enable" flag in the file system configuration.
> >For better or for worse, POSIX.1e defines that getfacl() will print the
> >current file permissions as an ACL if ACLs aren't available on the file
> >system. As such, you're probably just seeing the results of stat()
> >printed in an ACL form.
> I use UFS1. In DP1, the ACL works nice. But in DP2, I have never succeeded.
> in DP1, there is no need to add the 'acls' to 'fstab'. Anyway, I also add
> the 'acls' flag to 'fstab', but it fails, too.
> The system always say:
> Current#cd /usr/
> Current#setfacl -m u:oyk:r src
> setfacl: acl_get_file() failed: Operation not supported
If you run mount, does it show the "acls" flag for /usr? I generally
recommend that the tunefs flag be used to start ACLs on a file system
rather than the fstab flag, since that will prevent races and issues with
re-mounting for /. Try the following:
tunefs -a enable /dev/{deviceof/usr}
then unmount and remount the file system (probably by rebooting). Here's
the procedure I use to test ACLs locally when I don't want to mess with a
live file system:
alsvid# mdconfig -a -t malloc -s4m
md0
alsvid# newfs /dev/md0
/dev/md0: 4.0MB (8192 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 1.02MB, 65 blks, 256 inodes.
super-block backups (for fsck -b #) at:
32, 2112, 4192, 6272
alsvid# mount /dev/md0 /mnt
alsvid# cd /mnt
alsvid# mkdir -p .attribute/system
alsvid# cd .attribute/system/
alsvid# extattrctl initattr -p . 388 posix1e.acl_access
alsvid# extattrctl initattr -p . 388 posix1e.acl_default
alsvid# cd /mnt
alsvid# setfacl -m u:robert:r .
setfacl: acl_get_file() failed: Operation not supported
alsvid# cd /
alsvid# umount /mnt
alsvid# tunefs -a enable /dev/md0
tunefs: ACLs set
alsvid# mount /dev/md0 /mnt
alsvid# mount
/dev/ad0s1a on / (ufs, NFS exported, local, soft-updates)
devfs on /dev (devfs, local, multilabel)
/dev/md0 on /mnt (ufs, local, acls)
alsvid# setfacl -m u:robert:r .
alsvid# ls -la
total 5
drwxr-xr-x+ 3 root wheel 512 Dec 5 10:40 .
drwxr-xr-x 20 root wheel 1024 Nov 29 16:00 ..
drwxr-xr-x 3 root wheel 512 Dec 5 10:40 .attribute
alsvid# getfacl .
#file:.
#owner:0
#group:0
user::rwx
user:robert:r--
group::r-x
mask::r-x
other::r-x
Try using tunefs and see how things go. BTW, we're generally recommending
the use of UFS2 with ACLs because the extended attribute support is
substantially faster and more reliable.
It looks like there may be a problem with the processing of the "acls"
flag as an argument of the mount command. I'll investigate locally and
see if that's the cause -- if so, that would result in what you're seeing.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1021205104032.70896G-100000>