Re: Why does Samba requires 777 permissions on /tmp
On 19/05/2013 03:56, Erich Dollansky wrote: Your problem must be caused by something else. At least, I cannot remember to ever have seen /tmp with a different setting than 0777. I hope you mean 1777 (drwxrwxrwt) there. That sticky bit is important. Without it there are a number of nasty attack possibilities involving things like using a race condition and craftily modifying a sym-link to trick root into overwriting an important file. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: Why does Samba requires 777 permissions on /tmp
Hi, On Sun, 19 May 2013 07:06:46 +0100 Matthew Seaman matt...@freebsd.org wrote: On 19/05/2013 03:56, Erich Dollansky wrote: Your problem must be caused by something else. At least, I cannot remember to ever have seen /tmp with a different setting than 0777. I hope you mean 1777 (drwxrwxrwt) there. That sticky bit is I only wanted to note that it is octal. important. Without it there are a number of nasty attack possibilities involving things like using a race condition and craftily modifying a sym-link to trick root into overwriting an important file. I did not think of this at all when I have written my response. Of course, it has to be set and it is set on my machine. I was focusing only on the fact that all users of a system must be able to write to /tmp. Erich Cheers, Matthew ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Why does Samba requires 777 permissions on /tmp
On Sat, 18 May 2013 19:52:19 -0500 sindrome sindr...@gmail.com wrote: Thanks for that tip. I was hoping that was the root of it but upon looking at my path, I don't have /tmp in there. II used to have the sticky bit set on there. I just re-set it but portupgrade still keeps barking because it's world writable. It seems that the conflict is Samba needs it to be world writable and portupgrade hates it. I have /tmp set to 1777, I use portupgrade and samba and it works fine... Perhaps check the setting of PATH with 'env' just in case it's getting set somewhere else? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Why does Samba requires 777 permissions on /tmp
On 19 May 2013 00:34, sindrome sindr...@gmail.com wrote: I just found myself troubleshooting an issue where my desktop machine couldn't login to my local samba server unless I have the /tmp directory permissions set to 777. I'd like to have it 775 not only for security reasons but also because portupgrade always barks when the tmp directory it set that way. Is there something that can be tweaked in smb.conf so that I can authenticate without that? This was in the logs which led me to the root of the problem. [2013/05/18 13:31:01, 0] smbd/service.c:191(set_current_service) chdir (/tmp) failed Once I changed it back to 777 the machine trust was working again. It seems that I could set the TMPDIR environmental variable to another directory but that's the very same variable that portupgrade uses so it would still have the same issue. These are the warnings that portupgrade gives if I keep the permissions that way. /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:483: warning: Insecure world writable dir /tmp in PATH, mode 040777 /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:1170: warning: Insecure world writable dir /tmp in PATH, mode 040777 /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgmisc.rb:108: warning: Insecure world writable dir /tmp in PATH, mode 040777 Any thoughts on how I can make Samba not require 777 on /tmp? It is quite honestly an awful idea to have /tmp in your PATH. Remove it, and the complaints will stop. Consider an attacker dropping a load of executables into /tmp, perhaps called portupgrad. You tab-complete as root, and run that instead Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [texlive, FreeBSD 10.x-amd64] build error: _ThreadRuneLocale: TLS definition in /usr/lib/libc.so section .tbss mismatches non-TLS reference in gsftopk.o
Hi Steve, 2013/5/19 Steve Wills swi...@freebsd.org: I had a similar issue with devel/kBuild recently. It may be due to -Dlint getting passed to the build. See this rev: [...] which defines _Thread_local as empty when lint is defined. This then affects runetype.h: http://svnweb.freebsd.org/base/head/include/runetype.h?annotate=232498pathrev=250623#l92 I'm not sure if this is a bug in cdefs.h, runetype.h or things building with -Dlint or none of the above. Comments would be appreciated. This is a bit of a weird issue, which I didn't expect. It seems that we have various ports that actually *compile* code using -Dlint. I thought it was only used by tools like xlint, which only process source code. I've reverted the change to sys/cdefs.h. Thanks for reporting the issue! -- Ed Schouten e...@80386.nl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [patch included] teTeX and TeXLive
On Sun, 19 May 2013 07:08:40 +0900 (JST) Hiroki Sato h...@freebsd.org wrote: Christopher J. Ruwe c...@cruwe.de wrote in 20130518025801.0659b...@dijkstra.cruwe.de: cj I have included the patches, they are rather trivial, although, I cj think, dirty. I have also included a complete logfile of a failed cj build for tex-formats. Where is the log file? What I need to investigate here is a build+install log for print/texlive-base on your environment. Running texconfig rehash in pre-install just hides your error and makes another problem. -- Hiroki I am sorry, must have bungled the files. Here it is. What do you mean by build+install log? I hope it is the phase: partitions in poudriere's logfile. If it is not, could you help me producing these? Many thanks for your efforts. -- Christopher TZ: GMT + 2h GnuPG/GPG: 0xE8DE2C14 FreeBSD 9.1-RELEASE #2: Tue Nov 27 03:45:16 UTC 2012 root@darkstar:/usr/obj/pcbsd-build90/fbsd-source/9.1/sys/GENERIC Punctuation matters: Lets eat Grandma or Lets eat, Grandma - Punctuation saves lives. A panda eats shoots and leaves or A panda eats, shoots, and leaves - Punctuation teaches proper biology. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ chinese/qe | 0.1.1 | 0.2.0 +-+ devel/py-repoze.who | 2.0 | 2.2 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt If wish to stop receiving portscout reminders, please contact portsc...@portscout.freebsd.org Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Since some time (weeks?) www/opera is hanging on 9-STABLE amd64 clang
While playing certain html5/gstreamer/webm content e.g. youtube. Can anybody confirm? -- View this message in context: http://freebsd.1045724.n5.nabble.com/Since-some-time-weeks-www-opera-is-hanging-on-9-STABLE-amd64-clang-tp5813142.html Sent from the freebsd-ports mailing list archive at Nabble.com. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Why does Samba requires 777 permissions on /tmp
I checked everywhere (in .cshrc etc..) as well as echo $PATH and /tmp is not in there. I'm not sure where it's picking up /tmp in the path On Sun, May 19, 2013 at 2:36 AM, Chris Rees utis...@gmail.com wrote: On 19 May 2013 00:34, sindrome sindr...@gmail.com wrote: I just found myself troubleshooting an issue where my desktop machine couldn't login to my local samba server unless I have the /tmp directory permissions set to 777. I'd like to have it 775 not only for security reasons but also because portupgrade always barks when the tmp directory it set that way. Is there something that can be tweaked in smb.conf so that I can authenticate without that? This was in the logs which led me to the root of the problem. [2013/05/18 13:31:01, 0] smbd/service.c:191(set_current_service) chdir (/tmp) failed Once I changed it back to 777 the machine trust was working again. It seems that I could set the TMPDIR environmental variable to another directory but that's the very same variable that portupgrade uses so it would still have the same issue. These are the warnings that portupgrade gives if I keep the permissions that way. /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:483: warning: Insecure world writable dir /tmp in PATH, mode 040777 /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:1170: warning: Insecure world writable dir /tmp in PATH, mode 040777 /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgmisc.rb:108: warning: Insecure world writable dir /tmp in PATH, mode 040777 Any thoughts on how I can make Samba not require 777 on /tmp? It is quite honestly an awful idea to have /tmp in your PATH. Remove it, and the complaints will stop. Consider an attacker dropping a load of executables into /tmp, perhaps called portupgrad. You tab-complete as root, and run that instead Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Why does Samba requires 777 permissions on /tmp
On Sun, 19 May 2013 09:57:52 -0500 sindrome articulated: I checked everywhere (in .cshrc etc..) as well as echo $PATH and /tmp is not in there. I'm not sure where it's picking up /tmp in the path Same here. I have no idea where it is getting tmp from. At least it doesn't appear to be causing any problems. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ Bershere's Formula for Failure: There are only two kinds of people who fail: those who listen to nobody ... and those who listen to everybody. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [texlive, FreeBSD 10.x-amd64] build error: _ThreadRuneLocale: TLS definition in /usr/lib/libc.so section .tbss mismatches non-TLS reference in gsftopk.o
19.05.2013 11:45, Ed Schouten пишет: Hi Steve, 2013/5/19 Steve Wills swi...@freebsd.org: I had a similar issue with devel/kBuild recently. It may be due to -Dlint getting passed to the build. See this rev: [...] which defines _Thread_local as empty when lint is defined. This then affects runetype.h: http://svnweb.freebsd.org/base/head/include/runetype.h?annotate=232498pathrev=250623#l92 I'm not sure if this is a bug in cdefs.h, runetype.h or things building with -Dlint or none of the above. Comments would be appreciated. This is a bit of a weird issue, which I didn't expect. It seems that we have various ports that actually *compile* code using -Dlint. I thought it was only used by tools like xlint, which only process source code. I've reverted the change to sys/cdefs.h. Thanks for reporting the issue! That fixed texlive. Thanks! -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: QGIS With Grass Plugin doesn't build (kpty.cpp)
Perfect ! This patch works also good for me. Many thanks. -- View this message in context: http://freebsd.1045724.n5.nabble.com/QGIS-With-Grass-Plugin-doesn-t-build-kpty-cpp-tp5812385p5813188.html Sent from the freebsd-ports mailing list archive at Nabble.com. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Why does Samba requires 777 permissions on /tmp
On 19 May 2013 16:52, Jerry je...@seibercom.net wrote: On Sun, 19 May 2013 09:57:52 -0500 sindrome articulated: I checked everywhere (in .cshrc etc..) as well as echo $PATH and /tmp is not in there. I'm not sure where it's picking up /tmp in the path Same here. I have no idea where it is getting tmp from. At least it doesn't appear to be causing any problems. Is that with portupgrade too? Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Python 3.3 don't build
On Sun, 19 May 2013 18:29:28 +0200
Albert Shih articulated:
Hi all
Just report the
/usr/ports/lang/python33
don't build on
FreeBSD 9.1-STABLE #3 r250807: Sun May 19 17:48:52 CEST 2013
all other ports are up2date.
Here the output :
{truncated}
You would be better served by reporting this to: pyt...@freebsd.org.
You might also want to file a PR against it. I would suggest that you
do a make clean first, update your ports tree and then try to
rebuild the port with its default config settings. You can use script
to make a complete log of the build.
--
Jerry ♔
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
__
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Why does Samba requires 777 permissions on /tmp
Chris, I'm not sure I understand your question. Portupgrade barks about the /tmp directory being world writable. I pasted the exact errors earlier in this thread. I looked in my path and can't find /tmp in there and can't figure how to get rid of ruby complaining unless I remove the writable permissions. When I do that my windows desktop can't authenticate to my samba server. There has to be a root of this problem to make them both work. Is there some other place portupgrade is having /tmp amended on without it being in my $PATH? On Sun, May 19, 2013 at 11:48 AM, Chris Rees utis...@gmail.com wrote: On 19 May 2013 16:52, Jerry je...@seibercom.net wrote: On Sun, 19 May 2013 09:57:52 -0500 sindrome articulated: I checked everywhere (in .cshrc etc..) as well as echo $PATH and /tmp is not in there. I'm not sure where it's picking up /tmp in the path Same here. I have no idea where it is getting tmp from. At least it doesn't appear to be causing any problems. Is that with portupgrade too? Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Why does Samba requires 777 permissions on /tmp
On Sun, 19 May 2013 13:34:49 -0500 sindrome sindr...@gmail.com wrote: I'm not sure I understand your question. Portupgrade barks about the /tmp directory being world writable. I pasted the exact errors earlier in this thread. I looked in my path and can't find /tmp in there and can't figure how to get rid of ruby complaining unless I remove the writable permissions. When I do that my windows desktop can't authenticate to my samba server. There has to be a root of this problem to make them both work. Is there some other place portupgrade is having /tmp amended on without it being in my $PATH? I went back and had a closer look at your error message. What I hadn't done (and neither had you, prior to that) was read and fully digest the error message. portupgrade is calling its 'system()' function to run a command. The Ruby runtime does a sanity check to make sure that the directories in the path are secure...and /tmp isn't. I suspect that portupgrade puts temporary scripts into /tmp, then executes them; this implies that it's probably chdir'ing to /tmp, then haveing '.' in thge path, or even just adding /tmp to the path, although I don't think so. Anyway, what's insecure is that you don't have the sticky bit set. If you use: chmod 1777 /tmp it ought to all work. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Why does Samba requires 777 permissions on /tmp
On Sun, 19 May 2013 13:34:49 -0500 sindrome articulated: On Sun, May 19, 2013 at 11:48 AM, Chris Rees utis...@gmail.com wrote: On 19 May 2013 16:52, Jerry je...@seibercom.net wrote: On Sun, 19 May 2013 09:57:52 -0500 sindrome articulated: I checked everywhere (in .cshrc etc..) as well as echo $PATH and /tmp is not in there. I'm not sure where it's picking up /tmp in the path Same here. I have no idea where it is getting tmp from. At least it doesn't appear to be causing any problems. Is that with portupgrade too? Chris, I'm not sure I understand your question. Portupgrade barks about the /tmp directory being world writable. I pasted the exact errors earlier in this thread. I looked in my path and can't find /tmp in there and can't figure how to get rid of ruby complaining unless I remove the writable permissions. When I do that my windows desktop can't authenticate to my samba server. There has to be a root of this problem to make them both work. Is there some other place portupgrade is having /tmp amended on without it being in my $PATH? If I am not mistaken, portupgrade only started with this BS about 6 months ago after it, itself was updated. It might be something hard coded by error into the program. I reported this once before to the port maintainer bdrew...@freebsd.org; however, I never received a response. Maybe I should file a PR against it. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Why does Samba requires 777 permissions on /tmp
On Sun, 19 May 2013 19:56:39 +0100 Bob Eager articulated: On Sun, 19 May 2013 13:34:49 -0500 sindrome sindr...@gmail.com wrote: I'm not sure I understand your question. Portupgrade barks about the /tmp directory being world writable. I pasted the exact errors earlier in this thread. I looked in my path and can't find /tmp in there and can't figure how to get rid of ruby complaining unless I remove the writable permissions. When I do that my windows desktop can't authenticate to my samba server. There has to be a root of this problem to make them both work. Is there some other place portupgrade is having /tmp amended on without it being in my $PATH? I went back and had a closer look at your error message. What I hadn't done (and neither had you, prior to that) was read and fully digest the error message. portupgrade is calling its 'system()' function to run a command. The Ruby runtime does a sanity check to make sure that the directories in the path are secure...and /tmp isn't. I suspect that portupgrade puts temporary scripts into /tmp, then executes them; this implies that it's probably chdir'ing to /tmp, then haveing '.' in thge path, or even just adding /tmp to the path, although I don't think so. Anyway, what's insecure is that you don't have the sticky bit set. If you use: chmod 1777 /tmp it ought to all work. I have the directory chmod set to 1777 and I still receive the error. It has been set at that for over two years. This problem only started after a portupgrade several months ago. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Why does Samba requires 777 permissions on /tmp
Jerry is right. I have it set to 1777 too and still receive the error On Sun, May 19, 2013 at 2:17 PM, Jerry je...@seibercom.net wrote: On Sun, 19 May 2013 19:56:39 +0100 Bob Eager articulated: On Sun, 19 May 2013 13:34:49 -0500 sindrome sindr...@gmail.com wrote: I'm not sure I understand your question. Portupgrade barks about the /tmp directory being world writable. I pasted the exact errors earlier in this thread. I looked in my path and can't find /tmp in there and can't figure how to get rid of ruby complaining unless I remove the writable permissions. When I do that my windows desktop can't authenticate to my samba server. There has to be a root of this problem to make them both work. Is there some other place portupgrade is having /tmp amended on without it being in my $PATH? I went back and had a closer look at your error message. What I hadn't done (and neither had you, prior to that) was read and fully digest the error message. portupgrade is calling its 'system()' function to run a command. The Ruby runtime does a sanity check to make sure that the directories in the path are secure...and /tmp isn't. I suspect that portupgrade puts temporary scripts into /tmp, then executes them; this implies that it's probably chdir'ing to /tmp, then haveing '.' in thge path, or even just adding /tmp to the path, although I don't think so. Anyway, what's insecure is that you don't have the sticky bit set. If you use: chmod 1777 /tmp it ought to all work. I have the directory chmod set to 1777 and I still receive the error. It has been set at that for over two years. This problem only started after a portupgrade several months ago. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Python 3.3 don't build
Hi! Just report the /usr/ports/lang/python33 don't build on FreeBSD 9.1-STABLE #3 r250807: Sun May 19 17:48:52 CEST 2013 all other ports are up2date. Same problem here, rm@ is working on it, as far as I know. -- p...@opsec.eu+49 171 3101372 7 years to go ! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Why does Samba requires 777 permissions on /tmp
On 05/19/13 20:56, Bob Eager wrote: On Sun, 19 May 2013 13:34:49 -0500 sindrome sindr...@gmail.com wrote: can't authenticate to my samba server. There has to be a root of this problem to make them both work. Is there some other place portupgrade is having /tmp amended on without it being in my $PATH? I went back and had a closer look at your error message. What I hadn't done (and neither had you, prior to that) was read and fully digest the error message. portupgrade is calling its 'system()' function to run a command. The Ruby runtime does a sanity check to make sure that the directories in the path are secure...and /tmp isn't. I suspect that portupgrade puts temporary scripts into /tmp, then executes them; this implies that it's probably chdir'ing to /tmp, then haveing '.' in thge path, or even just adding /tmp to the path, although I don't think so. Anyway, what's insecure is that you don't have the sticky bit set. If you use: chmod 1777 /tmp it ought to all work. Unfortunately it doesn't - for me at least! Here's the error I get from portupgrade on (all of) my FreeBSD boxes: [simon@vmserver02 ~]$ sudo portupgrade -pP sysutils/webmin --- Session started at: Sun, 19 May 2013 21:11:25 +0200 /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:288: warning: Insecure world writable dir /tmp/ in PATH, mode 041777 AFAIR this started around the time of the last Ruby update over a year ago, the change and subsequent rollback to making the default version of Ruby 1.9. I'm using 1.8.7 which I believe is still the FBSD default version. Is anyone seeing this issue using Ruby 1.9? I definitely do not have /tmp in my $PATH. Cheers Simon. smime.p7s Description: S/MIME Cryptographic Signature
Re: Why does Samba requires 777 permissions on /tmp
I concur with Simon. That's exactly when it started for me. On May 19, 2013, at 2:30 PM, Simon Wright simon.wri...@gmx.net wrote: On 05/19/13 20:56, Bob Eager wrote: On Sun, 19 May 2013 13:34:49 -0500 sindrome sindr...@gmail.com wrote: can't authenticate to my samba server. There has to be a root of this problem to make them both work. Is there some other place portupgrade is having /tmp amended on without it being in my $PATH? I went back and had a closer look at your error message. What I hadn't done (and neither had you, prior to that) was read and fully digest the error message. portupgrade is calling its 'system()' function to run a command. The Ruby runtime does a sanity check to make sure that the directories in the path are secure...and /tmp isn't. I suspect that portupgrade puts temporary scripts into /tmp, then executes them; this implies that it's probably chdir'ing to /tmp, then haveing '.' in thge path, or even just adding /tmp to the path, although I don't think so. Anyway, what's insecure is that you don't have the sticky bit set. If you use: chmod 1777 /tmp it ought to all work. Unfortunately it doesn't - for me at least! Here's the error I get from portupgrade on (all of) my FreeBSD boxes: [simon@vmserver02 ~]$ sudo portupgrade -pP sysutils/webmin --- Session started at: Sun, 19 May 2013 21:11:25 +0200 /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:288: warning: Insecure world writable dir /tmp/ in PATH, mode 041777 AFAIR this started around the time of the last Ruby update over a year ago, the change and subsequent rollback to making the default version of Ruby 1.9. I'm using 1.8.7 which I believe is still the FBSD default version. Is anyone seeing this issue using Ruby 1.9? I definitely do not have /tmp in my $PATH. Cheers Simon. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Why does Samba requires 777 permissions on /tmp
On Sun, 19 May 2013 21:30:03 +0200 Simon Wright articulated: On 05/19/13 20:56, Bob Eager wrote: On Sun, 19 May 2013 13:34:49 -0500 sindrome sindr...@gmail.com wrote: can't authenticate to my samba server. There has to be a root of this problem to make them both work. Is there some other place portupgrade is having /tmp amended on without it being in my $PATH? I went back and had a closer look at your error message. What I hadn't done (and neither had you, prior to that) was read and fully digest the error message. portupgrade is calling its 'system()' function to run a command. The Ruby runtime does a sanity check to make sure that the directories in the path are secure...and /tmp isn't. I suspect that portupgrade puts temporary scripts into /tmp, then executes them; this implies that it's probably chdir'ing to /tmp, then haveing '.' in thge path, or even just adding /tmp to the path, although I don't think so. Anyway, what's insecure is that you don't have the sticky bit set. If you use: chmod 1777 /tmp it ought to all work. Unfortunately it doesn't - for me at least! Here's the error I get from portupgrade on (all of) my FreeBSD boxes: [simon@vmserver02 ~]$ sudo portupgrade -pP sysutils/webmin --- Session started at: Sun, 19 May 2013 21:11:25 +0200 /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:288: warning: Insecure world writable dir /tmp/ in PATH, mode 041777 AFAIR this started around the time of the last Ruby update over a year ago, the change and subsequent rollback to making the default version of Ruby 1.9. I'm using 1.8.7 which I believe is still the FBSD default version. Is anyone seeing this issue using Ruby 1.9? I definitely do not have /tmp in my $PATH. Information for portupgrade-devel-20130313_1,3: Depends on: Dependency: libyaml-0.1.4_2 Dependency: openssl-1.0.1_8 Dependency: libffi-3.0.13 Dependency: libexecinfo-1.1_3 Dependency: ruby-1.9.3.392,1 Dependency: ruby19-date2-4.0.19 Dependency: db48-4.8.30.0 Dependency: ruby19-bdb-0.6.6_1 And yes, I have the same error message. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Why does Samba requires 777 permissions on /tmp
On Sun, 19 May 2013 21:30:03 +0200 Simon Wright simon.wri...@gmx.net wrote: On 05/19/13 20:56, Bob Eager wrote: On Sun, 19 May 2013 13:34:49 -0500 sindrome sindr...@gmail.com wrote: can't authenticate to my samba server. There has to be a root of this problem to make them both work. Is there some other place portupgrade is having /tmp amended on without it being in my $PATH? I went back and had a closer look at your error message. What I hadn't done (and neither had you, prior to that) was read and fully digest the error message. portupgrade is calling its 'system()' function to run a command. The Ruby runtime does a sanity check to make sure that the directories in the path are secure...and /tmp isn't. I suspect that portupgrade puts temporary scripts into /tmp, then executes them; this implies that it's probably chdir'ing to /tmp, then haveing '.' in thge path, or even just adding /tmp to the path, although I don't think so. Anyway, what's insecure is that you don't have the sticky bit set. If you use: chmod 1777 /tmp it ought to all work. Unfortunately it doesn't - for me at least! Here's the error I get from portupgrade on (all of) my FreeBSD boxes: [simon@vmserver02 ~]$ sudo portupgrade -pP sysutils/webmin --- Session started at: Sun, 19 May 2013 21:11:25 +0200 /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:288: warning: Insecure world writable dir /tmp/ in PATH, mode 041777 AFAIR this started around the time of the last Ruby update over a year ago, the change and subsequent rollback to making the default version of Ruby 1.9. I'm using 1.8.7 which I believe is still the FBSD default version. Is anyone seeing this issue using Ruby 1.9? I definitely do not have /tmp in my $PATH. As I said, that may not be the explicit problem. The message does seem to be from the ruby runtime. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Why does Samba requires 777 permissions on /tmp
From the original post that started this thread, I noticed that the error from portupgrade/ruby was showing the permissions that it didn't like as mode 040777 (octal). This is definitely with the sticky bit turned OFF. It should be 041777. 'stat -r /tmp' will print the permissions in octal rather than the '..rwx...' from ls -l; the permissions is the third group of numbers. Jimmy On Sun, May 19, 2013 at 03:12:08PM -0500, sindrome wrote: Jerry is right. I have it set to 1777 too and still receive the error On Sun, May 19, 2013 at 2:17 PM, Jerry je...@seibercom.net wrote: On Sun, 19 May 2013 19:56:39 +0100 Bob Eager articulated: On Sun, 19 May 2013 13:34:49 -0500 sindrome sindr...@gmail.com wrote: I'm not sure I understand your question. Portupgrade barks about the /tmp directory being world writable. I pasted the exact errors earlier in this thread. I looked in my path and can't find /tmp in there and can't figure how to get rid of ruby complaining unless I remove the writable permissions. When I do that my windows desktop can't authenticate to my samba server. There has to be a root of this problem to make them both work. Is there some other place portupgrade is having /tmp amended on without it being in my $PATH? I went back and had a closer look at your error message. What I hadn't done (and neither had you, prior to that) was read and fully digest the error message. portupgrade is calling its 'system()' function to run a command. The Ruby runtime does a sanity check to make sure that the directories in the path are secure...and /tmp isn't. I suspect that portupgrade puts temporary scripts into /tmp, then executes them; this implies that it's probably chdir'ing to /tmp, then haveing '.' in thge path, or even just adding /tmp to the path, although I don't think so. Anyway, what's insecure is that you don't have the sticky bit set. If you use: chmod 1777 /tmp it ought to all work. I have the directory chmod set to 1777 and I still receive the error. It has been set at that for over two years. This problem only started after a portupgrade several months ago. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Why does Samba requires 777 permissions on /tmp
On Sun, 19 May 2013 15:59:12 -0500 Jimmy ljboi...@gmail.com wrote: From the original post that started this thread, I noticed that the error from portupgrade/ruby was showing the permissions that it didn't like as mode 040777 (octal). This is definitely with the sticky bit turned OFF. It should be 041777. 'stat -r /tmp' will print the permissions in octal rather than the '..rwx...' from ls -l; the permissions is the third group of numbers. Well, that's true. And it is a security risk not to have the sticky bit on /tmp. Of course (for the avoidance of confusion) the 04 bit can't be changed, being the 'directory' bit. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: QGIS With Grass Plugin doesn't build (kpty.cpp)
Hi, Does this error exist on other FreeBSD version? I can not reproduce it on 10-Current and 9.0. wen 2013/5/20 GeoBSD pie...@geobsd.com Perfect ! This patch works also good for me. Many thanks. -- View this message in context: http://freebsd.1045724.n5.nabble.com/QGIS-With-Grass-Plugin-doesn-t-build-kpty-cpp-tp5812385p5813188.html Sent from the freebsd-ports mailing list archive at Nabble.com. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Python 3.3 builds with clang 32 on FreeBSd 9.1
I can say that it builds with FreeBSD 9.1 and clang 3.2 from /usr/bin/clang (native clang)... Strange... ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Can't build devel/qt4-corelib any more -- help?
On a system running: FreeBSD 9.1-STABLE #80 r250806: Sun May 19 04:54:21 PDT 2013 i386, I was performing my usual weekly update/refresh -- at this point, portmaster -ad --index. Other ports updated OK; other systems (including my laptop, which I update more frequently) were OK. First pass through, I saw the message: In file included from ../../include/QtCore/qatomic_arch.h:1, from ../../include/QtCore/../../src/corelib/thread/qbasicatomic .h:227, from ../../include/QtCore/qbasicatomic.h:1, from ../../include/QtCore/../../src/corelib/thread/qatomic.h:46 , from ../../include/QtCore/qatomic.h:1, from ../../include/QtCore/../../src/corelib/tools/qbytearray.h: 45, from ../../include/QtCore/qbytearray.h:1, from ../../include/QtCore/../../src/corelib/kernel/qobject.h:49 , from ../../include/QtCore/qobject.h:1, from ../../include/QtCore/../../src/corelib/thread/qthread.h:45 , from ../../include/QtCore/qthread.h:1, from ../../include/QtCore/private/../../../src/corelib/thread/q thread_p.h:58, from ../../include/QtCore/private/qthread_p.h:1, from global/qglobal.cpp:52: ../../include/QtCore/../../src/corelib/arch/qatomic_arch.h:96:4: error: #error Qt has not been ported to this architecture which I found a bit discouraging -- checking archives, there was a reason it looked a bit familiar. :-( However, as far as I can tell, I've been good about reviewing the ports/UPDATING instructions and using portmaster -r when that's mentioned. and the previous update was a week ago: FreeBSD 9.1-STABLE #79 r250556: Sun May 12 05:14:12 PDT 2013. On the off-chance that icu, pcre, or libffi had a missed update, I tried portmaster -r for each in turn, and proceeded OK up to qt4-corelib-4.8.4_1, which choked died -- e.g.: ... You have already accepted the terms of the license. rm -f endiantest.o rm -f *~ core *.core rm -f endiantest rm -f Makefile rm -f endiantest.o rm -f *~ core *.core rm -f endiantest rm -f Makefile cp: /common/ports/devel/qt4-corelib/work/qt-everywhere-opensource-src-4.8.4/src/ 3rdparty/webkit/Source/WebKit/qt/qt_webkit_version.pri: No such file or directory ln: /common/ports/devel/qt4-corelib/work/qt-everywhere-opensource-src-4.8.4/include/QtCore/qconfig.h: File exists ln: /common/ports/devel/qt4-corelib/work/qt-everywhere-opensource-src-4.8.4/include/Qt/qconfig.h: File exists This target is using the GNU C++ compiler (/usr/local/share/qt4/mkspecs/freebsd-g++). ... [and things degrade further beyond this point] So I thoiught that maybe somehow the prior installation of qt4-corelib was interfering with the attempt, so after running portmaster --check-depends (after which yet another attempt to portmaster devel/qt4-corelib still failed), I ran pkg_delete -f qt4-corelib-4.8.4_1 and tried portmaster devel/qt4-corelib again .. which *still* failed. The log may be seen at http://www.catwhisker.org/~david/FreeBSD/qt4_log.txt. What do I need to do to get devel/qt4-corelib installed on this system? Thanks. (No need to Cc: me; I'm subscribed to ports@.) Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpXLX4YzcwD6.pgp Description: PGP signature
Firefox 21.0 bus error and segfault
Hi all, I had just recently built Firefox 21.0 (my port version is 21.0_1,1) and I have been running into both bus errors and segfaults, depending on how I build Firefox. I usually build my ports via portupgrade and use portconf for options. With Firefox, I have GIO, LOGGING, and WEBRTC unset, and I have OPTIMIZED_CFLAGS set. I am running 8.3-RELEASE-p4 on amd64. When I build Firefox with just the above, I get a bus error with the following backtrace in gdb: Program received signal SIGBUS, Bus error. [Switching to Thread 8013021c0 (LWP 100207 initial thread)] 0x00419d55 in realloc () (gdb) bt #0 0x00419d55 in realloc () #1 0x000800fca61e in ?? () from /lib/libc.so.7 #2 0x000800fca9b1 in ?? () from /lib/libc.so.7 #3 0x000800fcb23c in setenv () from /lib/libc.so.7 #4 0x00402510 in ?? () #5 0x00402a9e in _start () I have also tried to build Firefox with DEBUG set and OPTIMIZED_CFLAGS unset. When I do this, Firefox runs, but I then run into a segfault if I do enough back and forth browsing in a single tab. Unfortunately I cannot reproduce this reliably. I get the following inside of gdb: Assertion failure: mDocument-IsXUL() || mDocument-GetReadyStateEnum() == nsIDocument::READYSTATE_INTERACTIVE || (mDocument-GetReadyStateEnum() == nsIDocument::READYSTATE_UNINITIALIZED NS_IsAboutBlank(mDocument-GetDocumentURI())) (Bad readystate), at /usr/ports/www/firefox/work/mozilla-release/layout/base/nsDocumentViewer.cpp:1029 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8013021c0 (LWP 101982 initial thread)] 0x0008023dd14e in ?? () from /usr/local/lib/firefox/libxul.so (gdb) bt #0 0x0008023dd14e in ?? () from /usr/local/lib/firefox/libxul.so #1 0x000803643f88 in ?? () from /usr/local/lib/firefox/libxul.so #2 0x0008036435b0 in ?? () from /usr/local/lib/firefox/libxul.so #3 0x0008036774dd in ?? () from /usr/local/lib/firefox/libxul.so #4 0x0008036763a9 in ?? () from /usr/local/lib/firefox/libxul.so #5 0x000803675f98 in ?? () from /usr/local/lib/firefox/libxul.so #6 0x000803675a3f in ?? () from /usr/local/lib/firefox/libxul.so #7 0x00080205022d in ?? () from /usr/local/lib/firefox/libxul.so #8 0x000802197668 in ?? () from /usr/local/lib/firefox/libxul.so #9 0x000802041b54 in ?? () from /usr/local/lib/firefox/libxul.so #10 0x0008020412d8 in ?? () from /usr/local/lib/firefox/libxul.so #11 0x0008045cb4f7 in ?? () from /usr/local/lib/firefox/libxul.so #12 0x0008045f1321 in ?? () from /usr/local/lib/firefox/libxul.so #13 0x0008045763d2 in ?? () from /usr/local/lib/firefox/libxul.so #14 0x000803bf18e0 in ?? () from /usr/local/lib/firefox/libxul.so #15 0x00080464da85 in ?? () from /usr/local/lib/firefox/libxul.so #16 0x00080464da16 in ?? () from /usr/local/lib/firefox/libxul.so #17 0x00080464d9a7 in ?? () from /usr/local/lib/firefox/libxul.so #18 0x000803a76452 in ?? () from /usr/local/lib/firefox/libxul.so #19 0x000803746d4c in ?? () from /usr/local/lib/firefox/libxul.so #20 0x000801ff88d6 in ?? () from /usr/local/lib/firefox/libxul.so #21 0x000801ff8b97 in ?? () from /usr/local/lib/firefox/libxul.so #22 0x000801ff8db2 in XRE_main () from /usr/local/lib/firefox/libxul.so #23 0x0040322b in ?? () #24 0x0040360c in ?? () #25 0x004025de in _start () I'm not sure why the backtrace with DEBUG set still shows no debugging symbols. In any case, regarding the bus error, I have no idea why this is happening. I have not updated FreeBSD itself, and I had Firefox 20 running fine prior to the update to Firefox 21, but after Firefox 21, even Firefox 20 gives me a bus error (it's pretty much the same backtrace as above). The only other thing I can point out is that I have libstdc++.so.6 and libgcc_s.so.1 libmapped to the gcc47 versions of those. Thanks, Naram Qashat ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Why does Samba requires 777 permissions on /tmp
You can see the sticky bit is indeed set and I'm still getting these errors: stat -r /tmp 90 7418880 041777 3 0 0 29641368 512 1368950908 1369024120 1369024120 1130953852 16384 4 0 /tmp /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:483: warning: Insecure world writable dir /tmp/. in PATH, mode 041777 /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:1170: warning: Insecure world writable dir /tmp/. in PATH, mode 041777 /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgmisc.rb:108: warning: Insecure world writable dir /tmp/. in PATH, mode 041777 /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:483: warning: Insecure world writable dir /tmp/. in PATH, mode 041777 On Sun, May 19, 2013 at 4:22 PM, Bob Eager r...@tavi.co.uk wrote: On Sun, 19 May 2013 15:59:12 -0500 Jimmy ljboi...@gmail.com wrote: From the original post that started this thread, I noticed that the error from portupgrade/ruby was showing the permissions that it didn't like as mode 040777 (octal). This is definitely with the sticky bit turned OFF. It should be 041777. 'stat -r /tmp' will print the permissions in octal rather than the '..rwx...' from ls -l; the permissions is the third group of numbers. Well, that's true. And it is a security risk not to have the sticky bit on /tmp. Of course (for the avoidance of confusion) the 04 bit can't be changed, being the 'directory' bit. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Why does Samba requires 777 permissions on /tmp
Hi, On Sun, 19 May 2013 23:31:21 -0500 sindrome sindr...@gmail.com wrote: You can see the sticky bit is indeed set and I'm still getting these errors: you must first realise that this is not an error but a warning /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:483: warning: Insecure world writable dir /tmp/. in PATH, mode 041777 Could it be that we all got this message but did not bother because we get so many warnings during an upgrade? Erich ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
