[389-devel] portability issue: scripts expecting /bin/sh to be bash
Hi I noticed that some shell scripts have bashisms in them, on Debian and it's derivatives /bin/sh is dash. A quick list of scripts shipped by 389-ds-base having this issue: monitor ldif2db ldif2ldap db2bak vlvindex dn2rdn restoreconfig saveconfig upgradedb suffix2instance dbverify but since I just ran all the scripts without any options, there might be others too that fail with unexpected operator errors etc when ran in a real environment. So maybe change all of them to use /bin/bash or migrate them to be posix compatible (and somehow test new ones for compliance)? -- t -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review (take #2) ticket 47699: Propagate plugin precedence to all registered function types
https://fedorahosted.org/389/attachment/ticket/47699/0002-Ticket-ticket47699-Propagate-plugin-precedence-to-al.patch taking into account Rich and Mark reviews -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Design review: Access control on entries specified in MODDN operation (ticket 47553)
Rich Megginson wrote: On 02/24/2014 09:00 AM, thierry bordaz wrote: Hello, IPA team filled this ticket https://fedorahosted.org/389/ticket/47553. It requires an ACI improvement so that during a MODDN a given user is only allowed to move an entry from one specified part of the DIT to an other specified part of the DIT. This without the need to grant the ADD permission. Here is the design of what could be implemented to support this need http://port389.org/wiki/Access_control_on_trees_specified_in_MODDN_operation regards thierry Since this not related to any Red Hat internal or customer information, we should move this discussion to the 389-devel list. Hi Thierry, Your design looks good. A minor question. The doc does not mention about deny. For instance, in your example DIT, can I allow moddn_to and moddn_from on the top dc=example,dc=com and deny them on cn=tests. Then, I can move an entry between cn=accounts and staging, but not to/from cn=tests? Or deny is not supposed to use there? Thanks, --noriko -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Design review: Access control on entries specified in MODDN operation (ticket 47553)
On 02/24/2014 02:47 PM, Noriko Hosoi wrote: Rich Megginson wrote: On 02/24/2014 09:00 AM, thierry bordaz wrote: Hello, IPA team filled this ticket https://fedorahosted.org/389/ticket/47553. It requires an ACI improvement so that during a MODDN a given user is only allowed to move an entry from one specified part of the DIT to an other specified part of the DIT. This without the need to grant the ADD permission. Here is the design of what could be implemented to support this need http://port389.org/wiki/Access_control_on_trees_specified_in_MODDN_operation regards thierry Since this not related to any Red Hat internal or customer information, we should move this discussion to the 389-devel list. Hi Thierry, Your design looks good. A minor question. The doc does not mention about deny. For instance, in your example DIT, can I allow moddn_to and moddn_from on the top dc=example,dc=com and deny them on cn=tests. Then, I can move an entry between cn=accounts and staging, but not to/from cn=tests? Or deny is not supposed to use there? In which entry do you set these ACIs? Do you set aci: (target=ldap:///cn=staging,dc=example,dc=com;)(version 3.0; acl MODDN from; allow (moddn_from)) userdn=ldap:///uid=admin_accounts,dc=example,dc=com; ;) in the cn=accounts,dc=example,dc=com entry? Do you set aci: (target=ldap:///cn=accounts,dc=example,dc=com;)(version 3.0; acl MODDN to; allow (moddn_to)) userdn=ldap:///uid=admin_accounts,dc=example,dc=com; ;) in the cn=staging,dc=example,dc=com entry? Thanks, --noriko -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
