site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com We have a product that uses an the older root tool helper process from MoreSecurity. We have installations of the product where the setuid-root bit doesn't seem to work. The program always asks for authentication (outside of the 5 minute timeout period). The tool lives in a framework inside of /Library/Frameworks. On other installations this works fine. On this installation, the setuid bit seems to have no affect. The system is connected to Active Directory if that makes any difference. What could be happening here? What situations would cause setuid-root to fail to launch a tool as root? -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Aug 27, 2009, at 11:41 AM, Duane Murphy wrote: If you are using exactly the code in MoreSecurity, it specifically states that calling AuthorizationCopyRights() will result in a dialog because of the default rule in /etc/authorization. If you are running it from an FS with the "nosuid" mount option, then it won't launch SUID, even if those are the permissions (check the output of the "mount" command for the FS in question, but in general, any portable device like a thumb drive or any non-local device like an NFS FS will have "nosuid"). If you are failing to call setuid(geteuid()) in the helper to set your saved, real and effective uid, the suid-ness will not be inherited by the child of the helper. If you are running a script instead of an actual binary, then the suid will always be ignored, unless the interpreter you are running it under is itself suid and capable of enforcing for/against suid-ness of the script (and it takes responsibility for the security when it does this; an example is suidperl). This email sent to site_archiver@lists.apple.com