[Mono-osx] Active Directory Infinite Loop
Jaume Llardén Prieto
jllarden at aim.com
Sat Jun 9 17:25:14 EDT 2007
Hi,
I'm reanimating this thread because I've been investigating this
issue for some time and I've arrived to some conclusions I'd like to
share with the list. Please correct me if any of my assumptions or
conclusions are wrong.
In my opinion the infinite loop is caused by a poor POSIX compliant
sysv semaphores implementation on Mac OS X. As already pointed out in
this list, this problem is not related to AD, but to UIDs over the 16-
bit boundary (larger than 65535).
The problem is that although semaphores can always be created (semget
works with small and with large UIDs), they can only be modified or
deleted with small UIDs. semget fails with large UIDs because the
owner UID of the semaphore is for some reason truncated to 16 bits
and then it doesn't match the "right" UID. The consequence: the owner
process gets a permission denied error.
It's difficult to say were things fail. Mac OS X provides several
mechanisms for supporting POSIX sysv semaphores, eg:
1) xnu/bsd/sys/ipc.h defines a POSIX compliant and a legacy version
of the ipc_perm struct. The kernel should be compiled with the POSIX
compliant version.
2) libc/sys/semctl.c defines a stub function is defined to account
for the difference in the ipc_perm struct.
[I downloaded libc and xnu from www.opensource.apple.com]
Debugging all this is quite time consuming. I couldn't arrive to a
conclusion yet (helper functions like kauth_cred_getuid don't make
things easy). It could be semget (xnu/bsd/kern/sysv_sem.c) failing to
save large creator UID/GID information (it would truncate it
instead). Or it could be semctl (also in xnu/bsd/kern/sysv_sem.c)
failing to retrieve the creator UID/GID information.
I thought of filing a bug to Apple, but wanted to hear some opinions
on this before.
Thanks,
jaume
PS:
You can test it yourself:
1) Create a user (I called it longuid) with System Preferences and
change the UID with NetInfo Manager to a value over 65535. Don't
forget to change as well the uid of its homedir and subdirectories.
2) Create a C file containing this code:
key_t mykey = 0xFEEDF00D;
int nsems = 1;
int flag = IPC_CREAT|IPC_EXCL;
int sem_id;
int status;
mode_t mode = 0666;
struct semid_ds sembuf;
union semun un;
sem_id = semget(mykey, nsems, flag|mode);
if (sem_id == -1) {
printf("Error creating set of semaphores: %s\n",strerror(errno));
exit(1);
} else {
printf("Created set of semaphores with ID: %d\n", sem_id);
}
status = semctl(sem_id,0,IPC_STAT,un);
if (status == -1) {
printf("Error getting semaphore information: %s\n", strerror(errno));
exit(1);
}
printf(
" uid = %d\n"
" gid = %d\n"
" mode = 0%03o\n"
" key = 0x%08lX\n",
(uid_t)sembuf.sem_perm.uid,
(gid_t)sembuf.sem_perm.gid,
(unsigned short)sembuf.sem_perm.mode,
(unsigned long)sembuf.sem_perm._key);
status = semctl(sem_id, 0, IPC_RMID);
if ( status == -1 ) {
printf("Error deleting semaphore: %s\n", strerror(errno));
exit(1);
} else {
printf("Deleted set of semaphores with ID: %d\n", sem_id);
}
3) Compile with -D__POSIX_C_SOURCE (to use the right version of the
ipc_perm struct) and run the program with your user ID and with longuid.
With my user ID everything worked fine: a semaphore was created, some
(correct) info was shown and then it was deleted.
With longuid the semaphore was created, the uid/gid information was
truncated at the 16-bit boundary and it the semaphore couldn't be
deleted.
On 5 Apr 2007, at 16:33, Daniel Abrams wrote:
> I appreciate this, it is at least some workaround, unfortunately in
> most cases these settings seem to be only available to a user with
> administrative rights, and having to manage each of these settings
> individually for each user on each machine would be a non-starter for
> most institutions, as they use LDAP and active directory to avoid this
> sort of management.
>
> But, its at least useful for getting started on a developer machine,
> so much appreciated, thanks!
>
> In general, I remain of the opinion that this needs to be fixed before
> Mono is useful as a general deployment environment on OS X, but I
> understand those who don't have users with active directory accounts,
> don't have an issue.
>
>
>
> On 4/5/07, Jaume Llardén Prieto <jllarden at aim.com> wrote:
>> Hi,
>>
>> There's a workaround: define the UID and GID in Directory Access.
>>
>> The whole process is:
>> Open Directory Access in Applications/Utilities, select Active
>> Directory in panel Services and press Configure. In the Advanced
>> Options, choose tab Mappings and choose a mapping. For my test I
>> chose UID to map to postalCode, UGID to primaryGroupID and GGID again
>> to postalCode (I needed a numeric attribute to play with and
>> postalCode was good enough). Then bind and you're done.
>>
>> I chose low values: uid=4055, ugid=513 and ggid=4055. And my
>> 'test.exe' worked. Without this workaround I suffered the described
>> problems.
>>
>> The catch is that you have to change the uid/gid of the home
>> directories of the affected users locally on every Mac.
>>
>> Kind regards
>> jaume
>>
>> On 4 Apr 2007, at 17:11, Daniel Abrams wrote:
>>
>> > uid=435092441
>> > gid=1309106314
>> >
>> > On 4/4/07, Eoin Norris <e.norris at mac.com> wrote:
>> >
>> > If you are running on an active directory account what is your gid
>> > and uid - the result of ( as you prob. know) typing id in the
>> > terminal?
>> >
>> > -- Eoin
>> >
>> > On 4 Apr 2007, at 15:57, Daniel Abrams wrote:
>> >
>> >>
>> >>
>> >> On 4/4/07, Eoin Norris < e.norris at mac.com> wrote:
>> >>
>> >> Well, my application is generally home-based but I would kinda
>> think
>> >> 15% of all users high, though it may be 15% of all macs deployed
>> >> across "schools, colleges, companies, government" but whatever
>> about
>> >> schools macs in the enterprise are extremely rare. So the total of
>> >> all macs is lower.
>> >>
>> >>
>> >> Perhaps. I worked for Apple in what was the Enterprise and
>> >> Education divisions, and I think my numbers are pretty
>> >> conservative, but maybe the ratio has shrunk. I can tell you that
>> >> one of my current clients is a large government agency, and macs
>> >> are not as rare as you might think, and they all use active
>> >> directory authentication.
>> >>
>> >>
>> >>
>> >> It is an issue for deployment as well. I am getting reports in the
>> >> field. I dont know specifically where to look in the Mono code
>> >> ( where it is happening) but the thread below ( taken from this
>> list)
>> >> gives some examples. The original poster does not seem to be on
>> the
>> >> list anymore, or not contributing to this new thread on the same
>> >> issue, but might be available on that email address.
>> >>
>> >> http://lists.ximian.com/pipermail/mono-osx/2006-January/
>> 000444.html
>> >>
>> >>
>> >> He clearly did some research and ascertained that it was an Apple
>> >> bug.
>> >>
>> >> I can't say if its an Apple bug or not. I could certainly believe
>> >> that POSIX threads are done differently in Mac OS X than in Linux,
>> >> and that the Apple implementation is incomplete or buggy, I don't
>> >> have much experience in that area. But I do know that in higher
>> >> level environments, Java, ObjC, etc, thread and process management
>> >> work fine on OS X and that many other development and deployment
>> >> environments have managed to solve threading issues without dying
>> >> early on Mac OS X. Unless it's solved, it effectively rules out
>> >> Mono development for us, but I understand that your mileage may
>> vary.
>> >>
>> >>
>> >
>> >
>> > _______________________________________________
>> > Mono-osx mailing list
>> > Mono-osx at lists.ximian.com
>> > http://lists.ximian.com/mailman/listinfo/mono-osx
>>
>>
More information about the Mono-osx
mailing list