March 2009 - Darwin-dev - lists.apple.com

Re: posix_spawn man page strangeness
by Terry Lambert 12 Mar '09

12 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com See also <sys/cdefs.h>. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Mar 11, 2009, at 3:55 PM, Stephane Sudre wrote: On Mar 11, 2009, at 3:53 PM, Andrew Gallatin wrote: Stéphane Sudre wrote: Is it a bug that the __restrict option is written behind the name of every parameters of the posix_spawn and posix_spawnp prototypes in the man page? It might be better readable without the "restrict" word. "restrict" is a C99 keyword that specifies that the referenced pointers to the function must not be aliased (point to the same memory location). This enables additional compiler optimizations. See http://www.cellperformance.com/mike_acton/2006/05/demystifying_the_restrict… I think having that information in the man page is helpful. The issue (I see) is not with the restrict meaning, it's with the reading because restrict is not a very often used keyword (it's the first time I see it). Additionally, the real prototype in spawn.h uses '__restrict' not 'restrict'. This is so that <sys/cdefs.h> can make the keyword go away if it's not supported by the compiler. For example, if you pass -std=c89 to the compiler because you have old code that will break with a newer compiler, or you use someone else's compiler that has not been updated to comply with the current standards. This email sent to site_archiver(a)lists.apple.com

1 0

Re: sysctl.proc_exec_affinity to force launching of 32-bit flavor?
by Eric Gouriou 12 Mar '09

12 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Mar 11, 2009, at 11:36 PM, Jim Correia wrote: Suppose I have a binary built with ppc, i386 and x86_64 architectures. Eric _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Also suppose that on a particular OS release, I want to ensure that when I exec that binary, the i386 variant runs, not the x86_64. For bundled applications, I can influence this through the LS keys. Before I exec the tool, I've tried setting sysctl.proc_exec_affinity to CPU_TYPE_X86 but the 64-bit version is executed. (Setting the affinity to ppc seems to work.) Am I overlooking something? I don't know about the sysctl and hope others will directly address your question. I know that posix_spawn() and posix_spawnattr_setbinpref_np() are frequently recommended in such cases. Launchd also has the BinaryOrderPreference key that is helpful in similar situations. This email sent to site_archiver(a)lists.apple.com

1 0

sysctl.proc_exec_affinity to force launching of 32-bit flavor?
by Jim Correia 12 Mar '09

12 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Suppose I have a binary built with ppc, i386 and x86_64 architectures. Am I overlooking something? Jim _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Also suppose that on a particular OS release, I want to ensure that when I exec that binary, the i386 variant runs, not the x86_64. For bundled applications, I can influence this through the LS keys. Before I exec the tool, I've tried setting sysctl.proc_exec_affinity to CPU_TYPE_X86 but the 64-bit version is executed. (Setting the affinity to ppc seems to work.) This email sent to site_archiver(a)lists.apple.com

1 0

Re: posix_spawn man page strangeness
by Stephane Sudre 11 Mar '09

11 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Mar 11, 2009, at 3:53 PM, Andrew Gallatin wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Stéphane Sudre wrote: Is it a bug that the __restrict option is written behind the name of every parameters of the posix_spawn and posix_spawnp prototypes in the man page? It might be better readable without the "restrict" word. "restrict" is a C99 keyword that specifies that the referenced pointers to the function must not be aliased (point to the same memory location). This enables additional compiler optimizations. See http://www.cellperformance.com/mike_acton/2006/05/ demystifying_the_restrict_keyw.html I think having that information in the man page is helpful. The issue (I see) is not with the restrict meaning, it's with the reading because restrict is not a very often used keyword (it's the first time I see it). Additionally, the real prototype in spawn.h uses '__restrict' not 'restrict'. This email sent to site_archiver(a)lists.apple.com

1 0

SRP and DirectoryService
by Robert Nilsson 11 Mar '09

11 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi, Thanks in advance, Robert Nilsson _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I am currently working on a client-server application where I would like to use the Secure Remote Password protocol (SRP, http://srp.stanford.edu/) for authentication of users as well as obtaining a good key to use for encrypting the rest of the "conversation". This part is not a problem. However, I would like to integrate this with DirectoryService (DS) so that I can authenticate users from (for example) an OD. Now the trouble begins. SRP requires that the server has access to the password either in clear-text or in some other directly derived form (SHA1 hash could be made to work). Hence I've been looking for a way to obtain this from DS or any other means, I've been thinking about creating a new authentication mechanism for SRP but I can't find any documentation about how to do that which might point to it not being supported. I'm just about to give up the SRP idea and use something supported, like CRAM-MD5, but these alternatives are not as attractive considering that there are known security flaws with some of them and they do not generate a good cryptographic key as a by-product either. Obviously my question is if anyone has any experience of doing something similar or has any ideas about how it might be done? This email sent to site_archiver(a)lists.apple.com

1 0

Re: posix_spawn man page strangeness
by Terry Lambert 11 Mar '09

11 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thanks, I wrote that man page. 8-). -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Mar 11, 2009, at 7:53 AM, Andrew Gallatin <gallatin(a)cs.duke.edu> wrote: Stéphane Sudre wrote: Is it a bug that the __restrict option is written behind the name of every parameters of the posix_spawn and posix_spawnp prototypes in the man page? It might be better readable without the "restrict" word. "restrict" is a C99 keyword that specifies that the referenced pointers to the function must not be aliased (point to the same memory location). This enables additional compiler optimizations. See http://www.cellperformance.com/mike_acton/2006/05/demystifying_the_restrict… I think having that information in the man page is helpful. It's also required by the POSIX standard that it be there. At the time, gcc could not actually implement it interior to array subscripts because gcc failed to fully comply with the c99 standard, which is one of the reasons we left the feature test for posix_spawn turned off in <unistd.h> (the code could not pass conformance testing with gcc as the c99 compiler). >From a technical point of view, I am really torn, since it's more or less the rebirth of noalias. DMR himself railed against noalias in defense of a posting by me hating the idea, and being piled onto in comp.lang.c by members of the X3J11 committee, which I have to admit was a pretty proud moment for me (google for the quoted phrase "noalias must go. This is non- negotiable."). On the other hand, in this very particular case, it lets us write an API in libc that can change its contract between user and kernel space without losing any binary compatibility, since all the data parameters are properly encapsulated by init/accessor/mutator/ destroy functions. The function is also odd in that it's the only one which directly returns its errno as its return value, another API design I happen to agree with wholeheartedly, but which it's far to late to retrofit everywhere, which leaves posix_spawn() the very odd man out. Either way, it's ruled by a standard which means strict conformance means improved source code portability for developers, so it's not going to change unless the change is mandated by The Austin Group and then documented by The Open Group. This email sent to site_archiver(a)lists.apple.com

1 0

Re: posix_spawn man page strangeness
by Andrew Gallatin 11 Mar '09

11 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1236783226; bh=9opZde+pH5nfpC8WR4I6kJzI9F31JHVKaq+fNZjAUQw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=U7X3eiUxApMt MyG2l/Pej+GVGrYWFRY2sWqd1+ax6Sfdc9ipd3exCG4DuGQPxdVu36jp1OdVMicvHHx 5gM4jGFexjK88Eo2qLA8eFf/OocCOWdwu9N9M/nAsI4JBkwuhnLx2oEpLthI+AfPHJ6 barSv+y/UcFksIn/DF1hS//IM= User-agent: Thunderbird 2.0.0.19 (X11/20090105) "restrict" is a C99 keyword that specifies that the referenced pointers to the function must not be aliased (point to the same memory location). This enables additional compiler optimizations. See http://www.cellperformance.com/mike_acton/2006/05/demystifying_the_restrict… I think having that information in the man page is helpful. Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Stéphane Sudre wrote: Is it a bug that the __restrict option is written behind the name of every parameters of the posix_spawn and posix_spawnp prototypes in the man page? It might be better readable without the "restrict" word. This email sent to site_archiver(a)lists.apple.com

1 0

posix_spawn man page strangeness
by Stéphane Sudre 11 Mar '09

11 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com It might be better readable without the "restrict" word. -------- Is it a bug that the __restrict option is written behind the name of every parameters of the posix_spawn and posix_spawnp prototypes in the man page? int posix_spawn(pid_t *restrict pid, const char *restrict path, const posix_spawn_file_actions_t *file_actions, const posix_spawnattr_t *restrict attrp, char *constargv[restrict], char *const envp[restrict]); _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: getpwnam() restricted in a chrooted environment?
by Axel Rau 10 Mar '09

10 Mar '09

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com Thanks, Terry, for responding, Sorry, Axel Am 10.03.2009 um 18:19 schrieb Terry Lambert: -- Terry On Mar 10, 2009, at 9:39 AM, Axel Rau <Axel.Rau(a)chaos1.de> wrote: Hi all, Is getpwnam() restricted some how in a chrooted environment? Any help greatly appreciated, Axel --- ar3 --- ar3 _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… not I created the chrooted environment, the the hylafax daemon does a chroot(). My problem has disappeared magically after a complete restart of all hylafax components. Most likely you failed to copy sufficient DS data files or plugins into your chroot environment; I believe the uucp user is stored in an XML file along side other local account files. You are aware that this code isn't going to actually work to lock access to the modem serial device becuase it puts its lock file in a subdirectory of /var and the /var in your chroot isn't the same as the one outside, so if access is contended inside and outside the chroot or in multiple chroot at the same time, then the programs won't see each others lock files, right? If you are planning to multiplex inbound and outbound fax and data or voice calls on the same device, rather than using it only for fax, you will need to come up with a different locking strategy that all parties respect, which probably means replacing this code completely. The hylafax code, as written, was really never intended to live in chroot environments. while installing hylafax 5.2.8 on darwin 9, getpwnam fails on the chrooted server. The relevant function is: ------------- void UUCPLock::setupIDs() { if (UUCPuid == (uid_t) -1) { const passwd *pwd = getpwnam("uucp"); if (!pwd) faxApp::fatal("Can not deduce identity of UUCP"); UUCPuid = pwd->pw_uid; UUCPgid = pwd->pw_gid; endpwent(); // paranoia } } ------------- Putting the code in a small c-program, it runs as expected. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/tlambert %40apple.com This email sent to tlambert(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: getpwnam() restricted in a chrooted environment?
by Terry Lambert 10 Mar '09

10 Mar '09

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com -- Terry On Mar 10, 2009, at 9:39 AM, Axel Rau <Axel.Rau(a)chaos1.de> wrote: Hi all, Is getpwnam() restricted some how in a chrooted environment? Any help greatly appreciated, Axel --- ar3 _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/tlambert%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Most likely you failed to copy sufficient DS data files or plugins into your chroot environment; I believe the uucp user is stored in an XML file along side other local account files. You are aware that this code isn't going to actually work to lock access to the modem serial device becuase it puts its lock file in a subdirectory of /var and the /var in your chroot isn't the same as the one outside, so if access is contended inside and outside the chroot or in multiple chroot at the same time, then the programs won't see each others lock files, right? If you are planning to multiplex inbound and outbound fax and data or voice calls on the same device, rather than using it only for fax, you will need to come up with a different locking strategy that all parties respect, which probably means replacing this code completely. The hylafax code, as written, was really never intended to live in chroot environments. while installing hylafax 5.2.8 on darwin 9, getpwnam fails on the chrooted server. The relevant function is: ------------- void UUCPLock::setupIDs() { if (UUCPuid == (uid_t) -1) { const passwd *pwd = getpwnam("uucp"); if (!pwd) faxApp::fatal("Can not deduce identity of UUCP"); UUCPuid = pwd->pw_uid; UUCPgid = pwd->pw_gid; endpwent(); // paranoia } } ------------- Putting the code in a small c-program, it runs as expected. This email sent to tlambert(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0