Conference tuxedo::dce-products

Hiroaki,

If you're attempting to *modify* the acl to change the permissions for
the acmsdemo group, then you should be using the -m switch, not the -d
switch.  If you are actually trying to remove that ACE for acmsdemo,
then you must have the proper credentials on that object to remove it.
Whomever has the 'd' privs looks like they'd be able to delete that
ACE. Who are you logged in as when you attempt this operation?

Laura

Thanks for your quick response.

>If you're attempting to *modify* the acl to change the permissions for
>the acmsdemo group, then you should be using the -m switch, not the -d

Although I've changed switch from '-d' to '-m' as followings, the result was
same.

C:\>acl_edit -addr "c47af84e-952e-11d0-9e2b-08002b3c1af8@ncadg_ip_udp:16.161.96.
dp:16.161.96.76[1078]" acmsuser -m group:acmsdemo:rw
ERROR: permission not valid for this acl (dce / sec)

I'll clarify the my question.

1. Is it possible to modify the ACE for namespace object using acl_edit?
2. Do I need to specify '-addr <address explanation>' instead of '-e 
   <pathname>' to change the ACE for this object?

My concern is whether the modification for namespace object require the assist 
of ACL security manager? If so, how do change this ACE attribute.

Thanks,
Hiroaki

I'm in still trouble.

I could not understand the use of 'ACL Masks' and how instance the ACL 
security from parent directory.

Does anyone have any idea?

Thanks,
Hiroaki

I've found the reason why the command was failed.

># SEC_ACL for /.:/acmsxp010/acmsuser:
># Default cell = /.../jwblue_cell
>unauthenticated:r--t-
>user:acmsuser:rwdtc
>group:subsys/dce/cds-admin:rwdtc
>group:subsys/dce/cds-server:rwdtc
>group:acmsdemo:rwdtc
>any_other:r--t-

I beleave that the above ACL is invalid. Because, both of 'group' entitiy
amd 'user' entity which belong to that group are exsists in the same ACL.
So all of my requests has been rejected.

I've removed 'group:acmsdemo' entry and I could modify the 'user:acmsuser'
entry.

Since I added 'group:acmsdemo:rwdtc' entry using '-ic' and '-io' option,
the above ACL has generated automatically.

Thanks
Hiroaki

Just confirmatin.

.4>I beleave that the above ACL is invalid. Because, both of 'group' entitiy
.4>amd 'user' entity which belong to that group are exsists in the same ACL.
.4>So all of my requests has been rejected.

Is this behavior DIGITAL specific? How treat this ACL on other vendor's DCE
products based on OSF/DCE?

Is this ACL, which has both 'group' and 'user' ACE, valid on other DCE
products or not?

Thanks,
Hiroaki

>Is this ACL, which has both 'group' and 'user' ACE, valid on other DCE
>products or not?
    
    It's valid on Digital DCE, too.  You haven't provided enough
    information for us to see what's going on.  The error you were getting,
    "permission not valid for this ACL" doesn't mean that your credentials
    didn't allow the operation, it means that one of the permissions you
    were trying to set isn't a valid permission.
    
    The operations you've posted all look reasonable, in that they only
    seem to be trying to set permission bits that already exist.  Can you
    get back to the state where operations were failing?  If so, try
    invoking acl_edit interactively and post the results of a "get_access"
    command and a "permissions" command.
    
    John

Thanks John.

Could you verify attached operation? After re-configured CDS using DCESetup,
I've operated as followings.

I think multiple '-io' switch cause this situation.

Hiroaki


C:\>dce_login cell_admin Decjapan
Login Successful

C:\>rgy_edit
Current site is: registry server at /.../jwblue_cell/subsys/dce/sec/master
rgy_edit=> domain group
Domain changed to: group
rgy_edit=> add webg1 -f "Web User Group 1"
rgy_edit=> add webg2 -f "Web User Group 2"
rgy_edit=> domain principal
Domain changed to: principal
rgy_edit=> add webp1 -f "Web User 1"
rgy_edit=> add webp2 -f "Web User 2"
rgy_edit=> domain account
Domain changed to: account
rgy_edit=> add webp1 -g webg1 -o none -pw webp1 -mp Decjapan
rgy_edit=> add webp2 -g webg2 -o none -pw webp2 -mp Decjapan
rgy_edit=> quit
bye.

C:\>acl_edit /.:/ -m group:webg1:rwdtcia
C:\>acl_edit /.:/ -ic -m group:webg1:rwdtcia
C:\>acl_edit /.:/ -io -m group:webg1:rwdtcia
C:\>acl_edit /.../jwblue_cell/jwblue_ch -m group:webg1:rwdtc

C:\> cdscp create directory /.:/animal

C:\>acl_edit /.:/animal -io -m user:webp1:rwdct

C:\>cdscp create object /.:/animal/dog

C:\>acl_edit -e /.:/animal/dog
sec_acl_edit> l

# SEC_ACL for /.:/animal/dog:
# Default cell = /.../jwblue_cell
unauthenticated:r--t-
user:webp1:rwdtc
user:cell_admin:rwdtc
group:subsys/dce/cds-admin:rwdtc
group:subsys/dce/cds-server:rwdtc
group:webg1:rwdtc
any_other:r--t-

C:\>acl_edit -e /.:/animal/dog
sec_acl_edit> l

# SEC_ACL for /.:/animal/dog:
# Default cell = /.../jwblue_cell
unauthenticated:r--t-
user:webp1:rwdtc
user:cell_admin:rwdtc
group:subsys/dce/cds-admin:rwdtc
group:subsys/dce/cds-server:rwdtc
group:webg1:rwdtc
any_other:r--t-
sec_acl_edit> modify user:webp2:rt
sec_acl_edit> co
ERROR: permission not valid for this acl ( dce / sec )	<- failed
sec_acl_edit> g
Granted permissions: rwdtc
sec_acl_edit> delete group:webg1
sec_acl_edit> co					<- Passed
sec_acl_edit> l

# SEC_ACL for /.:/animal/dog:
# Default cell = /.../jwblue_cell
unauthenticated:r--t-
user:webp1:rwdtc
user:cell_admin:rwdtc
user:webp2:r--t-
group:subsys/dce/cds-admin:rwdtc
group:subsys/dce/cds-server:rwdtc
any_other:r--t-
sec_acl_edit> ab

    OK, this is a bug, and it's not specific to Digital's DCE.
    
    The problem is that the "i" permission bit is not applicable to CDS
    objects (you can only insert objects in directories, not other
    objects), and CDS is correctly complaining when you try to commit an
    object ACL that has this bit set.  
    
    However, this same check isn't performed when you set the initial
    object ACL (the -io flag), so it's possible to setup an initiali object
    ACL that has this bit set, which will cause CDS to create object ACLs
    that have this bit set.  So you can get in a situation where acl_edit
    can list an ACL, but won't be able to commit it, even if you don't make
    any changes to it, as the following shows:
    
        C:\>acl_edit -e /.:/animal/dog
        sec_acl_edit> l
 
        # SEC_ACL for /.:/animal/dog:
        # Default cell = /.../jwblue_cell
        unauthenticated:r--t-
        user:webp1:rwdtc
        user:cell_admin:rwdtc
        group:subsys/dce/cds-admin:rwdtc
        group:subsys/dce/cds-server:rwdtc
        group:webg1:rwdtcia
        any_other:r--t-
        sec_acl_edit> co
        ERROR: permission not valid for this acl ( dce / sec )
    
    Note that I the display I get in the ACL list above includes the "i"
    bit on the group:webg1 entry; yours didn't, which implies you're
    running a pre-R1.1 CDS (in R1.1, CDS started listing all bits, even
    those that aren't relevant).
    
    The work-around is simply not to set the "i" bit on your initial object
    ACL (the only effect of doing so is to cause this error :)
    
    Another option is to upgrade your CDS directory version to V4, which
    supposedly fixes the problem (presumably by failing any attempts to set
    this bit on initial object ACLs).  You can only do this upgrade if all
    the CDS servers in your cell are based on the OSF R1.1 codebase or
    higher, and the procedure for doing so is documented in the CDS admin
    guide.
    
    John

Thanks for your explanation.

I understand completely.

Hiroaki

    I think the explanation in .8 would to the "a" bit as well as the "i"
    bit; neither bit is relevant for object ACLs, but both are erroneously
    permitted to be placed on the initial object ACL.
    
    John