I was wondering if anyone knows if there are any plans to fix Bug #1139 (reproduced below) in version 3.0.3. I haven't tried 3.0.3pre1 yet, but from what I read of the changes it doesn't look like this bug has been addressed.
Is there some other work around? This bug is quite annoying as some of our users/administrators would like to use Windows to modify ACLs and we recently migrated SIDs from NT4. I've tried setting the Algorithmic mapping base higher but this doesn't seem to help. Any help would be appreciated. Brandon Turner MSC Computer Operations BUG #1139: ---------------------------------------------------------------- How to reproduce that bug: After migrating users from NT4 to samba you get lots of RIDs that do not match the rid algorithm. As one such user, prefereably one with an odd RID, create a new file on some samba share with Linux ACL enabled. Now open the Properties->Security->??? dialog (Eigenschaften->Sicherheit->Berechtigungen in German) and change anything. Add write permission to everyone, for example. Now take a look at that file in the Linux filesystem, specially the ACL on that file. The owner has lost write permission and some group has got full access instead. The GID of this (possible not even existing) group is exactly the result of the RID algorithm calculation. What is happening?: My brief investigations indicate that the function create_canon_ace_lists() from posix_acls.c calls both sid_to_gid() and sid_to_uid() in turn with the same SID just to try if it matches in one case or the other. Unfortunately, sid_to_gid() falls back to algorithmic mapping and in the case shown above it succeeds to calculate a gid out of the migrated users RID. -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
