[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XFS/setfacl ordering bug still? - I think I Fixed ---- I think :) - "patch" included



After doing some gdb work and crap and downloading hte original setfacl port
from http://acl.bestbits.at I noticed the acl_check function wasn't allowing
more than one ACL_USER entry so:

libacl.c line 73:
                case ACL_USER:
                        if (state != ACL_USER)
                                FAIL_CHECK (ACL_MISS_ERROR);
                        if (ace->ae_id < qual || ace->ae_id ==
ACL_UNDEFINED_ID)
                                FAIL_CHECK (ACL_DUPLICATE_ERROR);
                        qual = ace->ae_id + 1;
should become:
                case ACL_USER:
                        if (state != ACL_USER)
                                FAIL_CHECK (ACL_MISS_ERROR);
                        if (ace->ae_id < qual || ace->ae_id ==
ACL_UNDEFINED_ID)
                                FAIL_CHECK (ACL_DUPLICATE_ERROR);
                        qual = ace->ae_id + 1;
                        needs_mask = 1;
                        break;


And its kickin!

At least its not spitting back pretty errors at me and my developers are
able to rwx files :)

Cheers!

Eric



----- Original Message -----
From: "Eric Peters" <eric@peters.org>
To: <linux-xfs@oss.sgi.com>
Sent: Saturday, August 25, 2001 11:04 AM
Subject: XFS/setfacl ordering bug still?


> # setfacl -R -m u:eric:rx /www
>
> gives a bunch of:
>
> setfacl: /www/vtc/www.vectortheater.org/inc: Resulting ACL
>
`user::rwx,user:www:r-x,user:tim:rwx,user:er1c:rwx,user:jc:r-x,user:eric:r-x
> ,group::--x,mask::rwx,other::rwx': Missing or wrong entry at entry 3
>
> Despite the acl_entry_sort(acl); additions,  I'm getting this type of
> error - like when it 'sorts' the entry its doing so alphabetically? like
it
> seems to me that its erroring because of the user:<uid> entries are
infront
> of the group/mask/other right?
>
> so is this happening because the acl_entry_sort(acl); is doing it just
> alphabetically when it really should be not?
>
> (I'm running hte latest CVS copy of the 'cmd'  - or were there perhaps
some
> alterations in the kernel for this too?
>
> Eric
>
>