http://blog.gmane.org/gmane.os.apple.macports.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.os.apple.macports.user/32179 <pre> This came up last month on macports-dev. http://thread.gmane.org/gmane.os.apple.macports.devel/22418 The short answer, to quote snc: vq </pre> Lawrence Velázquez 2013-05-19T04:25:36 http://permalink.gmane.org/gmane.os.apple.macports.user/32178 <pre>Hi, I have a Mac running OS X 10.8.3 "mountain lion" with Macports 2.1.3 installed. Among my many ports installed and active are: python24 &lt; at &gt;2.4.6_10 (active) python27 &lt; at &gt;2.7.3_1 (active) python33 &lt; at &gt;3.3.0_0 (active) Curiously, I noticed something quite interesting. Look at the subtle difference between 2.7 and 3.3 with respect to the following: For Python 2.7: /opt/local//Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/ For Python 3.3: /opt/local/Library/Frameworks/Python.framework/Versions/3.3/include/python3.3m/ With 3.3, why is there a lower case "m" appended to the directory path name above, whereas that's not the case with 2.7? Thanks, -Tabitha </pre> Tabitha McNerney 2013-05-19T03:41:58 http://permalink.gmane.org/gmane.os.apple.macports.user/32177 <pre> Lion's dyld does not print any messages when it prunes the environment. https://github.com/aosm/dyld/blob/195.6/src/dyld.cpp#L1469 vq </pre> Lawrence Velázquez 2013-05-18T04:58:25 http://permalink.gmane.org/gmane.os.apple.macports.user/32176 <pre>Sounds to me like something (.profile, .bash_profile, .login, .bashrc, .cshrc, etc?) is setting those DYLD environment variables under the one account, but not under the other. Ignoring them is legitimate. DYLD checks using issetugid(2) to decide whether to ignore them*. That's a security issue, since they could otherwise be used to cause the privileged program to do something other than what it was intended to do, and grant its privileges in a way that could be abused. * For low-level stuff like that, there's a good chance it's open source. If you google for the error message plus site:opensource.apple.gov you'll probably find the source code reference. And googling for the error message without that certainly finds plenty of references to discussion about it. It's a harmless message, and if there is some legitimate reason for those to be set, you can either ignore it, or find the program that actually needed them set and create a wrapper script that sets them just for it, so they don't have to be set for everything else and generating needless messages (and just possibly causing other problems). Most of the DYLD_ variables should be for debugging or working around some problem, NOT for use all the time with everything in a session. As to what changed, no idea. I'm running Lion (10.7.x), and have never seen those messages, although I knew they existed. I've played with Mountain Lion a bit under Parallels too, and don't recall seeing it there either. So I must not have done or installed whatever was setting those. </pre> Richard L. Hamilton 2013-05-17T23:52:08 http://permalink.gmane.org/gmane.os.apple.macports.user/32175 <pre> On May 17, 2013, at 08:28, Lawrence Velázquez wrote: It's been done: https://trac.macports.org/changeset/106166 It doesn't seem so objectionable to me. Anyone who has permission to run `sudo` is an administrator, who by definition is the one who makes decisions about what software to use on the computer. </pre> Ryan Schmidt 2013-05-17T21:10:50 http://permalink.gmane.org/gmane.os.apple.macports.user/32174 <pre> Yes. You'll note that the message you posted starts with "dyld". dyld is the dynamic loader. It's responsible for locating and loading dynamic libraries into memory when a process needs them. Ordinarily, dyld's behavior is affected by LD_LIBRARY_PATH and a plethora of DYLD_* variables (see the dyld(1) man page for a list). This would pose a security risk if the process in question were running with the privileges of its owner (often root) rather than those of the user who executed it (which is what setuid/setgid means). I don't know where you're getting this impression. It does not matter where the "export" statement is. It could be in .bashrc, .bash_profile, .profile, or some random script in /usr/local/lib/bin/foo/bar/baz/whatever; you could have run it manually at the prompt. As long as DYLD_* or LD_LIBRARY_PATH is in your environment, dyld will throw a warning when running setuid/setgid executables. vq </pre> Lawrence Velázquez 2013-05-17T20:42:06 http://permalink.gmane.org/gmane.os.apple.macports.user/32173 <pre> It is the stub compiled into every program (yes, *every* program) that loads its dylibs. "man dyld" Because the former are not run automatically, while .bashrc is loaded by every interactive shell and .bash_profile is loaded by every login shell (roughly, the first shell run when you open a terminal). </pre> Brandon Allbery 2013-05-17T20:34:26 http://permalink.gmane.org/gmane.os.apple.macports.user/32172 <pre> Correct, dyld removes all DYLD_* variables (the most common being DYLD_LIBRARY_PATH), plus LD_LIBRARY_PATH. https://github.com/aosm/dyld/blob/210.2.3/src/dyld.cpp#L1495 vq </pre> Lawrence Velázquez 2013-05-17T20:08:35 http://permalink.gmane.org/gmane.os.apple.macports.user/32171 <pre> On 17 May 2013, at 08:42 PM, Mike Alexander &lt;mta&lt; at &gt;umich.edu&gt; wrote: Not true. Setting LD_LIBRARY_PATH also triggers the warning. Chris </pre> Chris Jones 2013-05-17T20:07:16 http://permalink.gmane.org/gmane.os.apple.macports.user/32170 <pre>--On May 17, 2013 2:42:10 PM -0400 Lawrence Velázquez &lt;larryv&lt; at &gt;macports.org&gt; wrote: Actually, I think it can be any DYLD_* environment variable. I just tried setting DYLD_QQSV to something and got the warning. LD_* variables don't seem to trigger the warning. Mike _______________________________________________ macports-users mailing list macports-users&lt; at &gt;lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users </pre> Mike Alexander 2013-05-17T19:42:17 http://permalink.gmane.org/gmane.os.apple.macports.user/32169 <pre> I am aware of that Nothing is installed there should interfere You say "dyld removes those variables from its environment " what is dyld? A program? Please forgive my ignorance and why when "export LD_LIBRARY_PATH=/usr/local/bioinfosoft/genometools/lib" is sourced from a file located outside the 'admin' directory is a problem whereas if it is sourced from one of the .bash* files is not? Thanks --R vq </pre> Rodolfo Aramayo 2013-05-17T19:39:36 http://permalink.gmane.org/gmane.os.apple.macports.user/32168 <pre> Be aware that, as a rule, we do not support having other software installed in /usr/local. https://trac.macports.org/wiki/FAQ#usrlocal No. The warning has nothing to do with bash. The issue is the existence of LD_LIBRARY_PATH or DYLD_LIBRARY_PATH; dyld removes those variables from its environment to prevent setuid/setgid executables from loading arbitrary dylibs. How those variables got into the environment is completely irrelevant. vq </pre> Lawrence Velázquez 2013-05-17T18:42:10 http://permalink.gmane.org/gmane.os.apple.macports.user/32167 <pre> to a file in: /usr/local and when I run the commands there I found: ./bashrc:export LD_LIBRARY_PATH=/usr/local/bioinfosoft/genometools/lib when I commented out that: LD_LIBRARY_PATH=/usr/local/bioinfosoft/genometools/lib the problem went away So now I understand it. It is in fact a security check that prevents sourcing and therefore activation of potentially malicious code If the code: export LD_LIBRARY_PATH=/usr/local/bioinfosoft/genometools/lib is inside the .bashrc file, then there is no problem, but if it is present in another file being sourced, then there is a warning because that code is not being read Is this correct? Thanks --R </pre> Rodolfo Aramayo 2013-05-17T18:20:34 http://permalink.gmane.org/gmane.os.apple.macports.user/32166 <pre> Do any of those bash dotfiles source anything else? vq </pre> Lawrence Velázquez 2013-05-17T17:44:19 http://permalink.gmane.org/gmane.os.apple.macports.user/32165 <pre> Oh YES I do, but I sent you the result of the command you suggested as I obtained it 4$ ls total 116 drwxr-xr-x+ 24 admin staff 816 May 17 03:21 ./ drwxr-xr-x+ 7 root admin 238 May 17 02:10 ../ -rw------- 1 admin staff 3 May 14 12:02 .CFUserTextEncoding -rw-r--r-- 1 admin staff 15364 May 15 17:29 .DS_Store drwx------ 2 admin staff 68 May 17 02:03 .Trash/ -rw-r--r-- 1 admin staff 982 Feb 24 15:50 .bash_aliases -rw------- 1 admin staff 2429 May 17 12:13 .bash_history -rw-r--r-- 1 admin staff 587 Mar 31 2012 .bash_logout -rw-r--r-- 1 admin staff 1263 May 15 14:03 .bash_profile -rw-r--r-- 1 admin staff 895 Mar 31 2012 .bashrc -rw-r--r-- 1 admin staff 13883 May 17 03:21 .emacs drwx------ 9 admin staff 306 Feb 24 15:54 .emacs.d/ -rw-r--r-- 1 admin staff 13898 Feb 24 16:09 .emacs~ drwx------ 3 admin staff 102 May 15 22:00 .ssh/ drwx------+ 3 admin staff 102 May 14 12:02 Desktop/ drwx------+ 5 admin staff 170 May 15 17:29 Documents/ drwx------+ 7 admin staff 238 May 15 07:25 Downloads/ drwx------+ 42 admin staff 1428 May 17 02:04 Library/ drwx------+ 3 admin staff 102 May 14 12:02 Movies/ drwx------+ 4 admin staff 136 May 17 02:04 Music/ drwx------+ 5 admin staff 170 May 14 21:08 Pictures/ drwxr-xr-x+ 4 admin staff 136 May 14 12:02 Public/ -rw-r--r-- 1 admin staff 17204 May 15 20:32 portfinal -rw-r--r-- 1 admin staff 27258 May 15 20:31 portinstalled </pre> Rodolfo Aramayo 2013-05-17T17:26:45 http://permalink.gmane.org/gmane.os.apple.macports.user/32164 <pre> I ALWAYS clean before reporting In this case it does not matter as the error persists and yes I should have sent both logs (here attached) Thanks --R </pre> Rodolfo Aramayo 2013-05-17T17:20:17 http://permalink.gmane.org/gmane.os.apple.macports.user/32163 <pre> You don't have any dotfiles? vq </pre> Lawrence Velázquez 2013-05-17T17:20:37 http://permalink.gmane.org/gmane.os.apple.macports.user/32162 <pre> grep: /Users/admin/.: Is a directory grep: /Users/admin/..: Is a directory grep: /Users/admin/.Trash: Is a directory grep: /Users/admin/.emacs.d: Is a directory grep: /Users/admin/.ssh: Is a directory grep: /Users/admin/..: Is a directory grep: /Users/admin/.Trash: Is a directory grep: /Users/admin/.emacs.d: Is a directory grep: /Users/admin/.ssh: Is a directory </pre> Rodolfo Aramayo 2013-05-17T17:09:57 http://permalink.gmane.org/gmane.os.apple.macports.user/32161 <pre>Hi, No, its not an Apple bug. Something in your dot files is setting it. What does &gt; grep LD_LIBRARY_PATH ~/.* &gt; grep DYLD_LIBRARY ~/.* Give ? Because it doesn't have the settings in one of the ~/.* files that the other one does, I would guess. Chris </pre> Chris Jones 2013-05-17T16:34:35 http://permalink.gmane.org/gmane.os.apple.macports.user/32160 <pre> Your log says otherwise. vq </pre> Lawrence Velázquez 2013-05-17T16:13:16 http://permalink.gmane.org/gmane.os.apple.macports.user/32159 <pre> But it is present, as you can check using env | grep DYLD. We cannot read your shell and environment startup files for you – you need to find it on your own. Those people are wrong, it certainly isn't, and that the loader filters those environment variables on setuid and setgid binaries is a good thing (because it would otherweise open up a huge security hole). Because its startup files do not set the variable. </pre> Clemens Lang 2013-05-17T14:58:25 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.apple.macports.user