Re: samba - SIGABRT
jhell writes: Hi, This was caused by your setting of the following: security.bsd.map_at_zero=0 You can reset that value to 1 and you should be alright to operate like normal otherwise you will have to compile samba over again with the above mentioned configure options. Yeah this caused the problem. I wonder how I could have find this by myself (google is not counting ;)) I mean, the Abort message is not very verbose what the problem is here. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: r197748 - base/stable/7/bin/sh/ 7.2-STABLE i386
On Thu, 8 Oct 2009 01:29 -0400, barney@ wrote: I believe you are wrong about prior behavior. sudo is from a port and is in /usr/local/bin. Any shell is going to expand the list of args *before* giving control to the executable. So the system will churn for a while before sudo gets to ask for the password. On Thu, Oct 08, 2009 at 12:59:36AM -0400, jhell wrote: r197748 | jilles | 2009-10-04 13:16:11 -0400 (Sun, 04 Oct 2009) | 7 lines MFC r197371: Mention that NUL characters are not allowed in sh(1) input. I do not consider this a bug because POSIX permits it and argument strings and environment variables cannot contain '\0' anyway. PR: bin/25542 Recently I have been noticing strange happenings of what I believe to be coming from the latest revision of /bin/sh. Prior to this revision it had not happened to the following examples. I am taking this as it could just be a following behavior in sudo due to fixing the first behavior in sh(1) but I am not sure and looking for feedback. How to repeat: ( Let me know if this is only me. ) # sudo rm -rf /usr/ports/*/*/work After issuing the above command the process waits for the list of (work) directories to be collected and ends by bombing out with pam timeout error. This could probably be easier seen with higher IO load but it has struck me kind of odd since I have not seen it at all till now. Also once it gets started you can not ^C the process until it has run the full directory tree. Behavior before, you could issue the command and it would ask you for your password before it would issue any IO to the disk. Is the new behavior called for adjusting your command to sh -c rm -rf /usr/blah/bloo/bla* ? Yeah, maybe. I might be just mixing up that I actually ran this as root instead of sudo from a user account. Its late and it had confused me as I had not seen a pam timeout error like that before that sh revision. My belief behind it was just that it was a subshell starting using sh but not handing it self back to sudo in time for authentication or something like that... IDK Ill keep investigating it later. Maybe something else is actually going on with my system that has not yielded its ugly head yet. Thanks for the feedback. -- ;; dataix.net!jhell 2048R/89D8547E 2009-09-30 ;; BSD since FreeBSD 4.2Linux since Slackware 2.1 ;; 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[releng_8 tinderbox] failure on i386/pc98
TB --- 2009-10-08 11:23:56 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-08 11:23:56 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2009-10-08 11:23:56 - cleaning the object tree TB --- 2009-10-08 11:24:17 - cvsupping the source tree TB --- 2009-10-08 11:24:17 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2009-10-08 11:24:44 - building world TB --- 2009-10-08 11:24:44 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-08 11:24:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-08 11:24:44 - TARGET=pc98 TB --- 2009-10-08 11:24:44 - TARGET_ARCH=i386 TB --- 2009-10-08 11:24:44 - TZ=UTC TB --- 2009-10-08 11:24:44 - __MAKE_CONF=/dev/null TB --- 2009-10-08 11:24:44 - cd /src TB --- 2009-10-08 11:24:44 - /usr/bin/make -B buildworld World build started on Thu Oct 8 11:24:44 UTC 2009 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] gzip -cn /src/sbin/ddb/ddb.8 ddb.8.gz === sbin/devd (all) c++ -O2 -pipe -I. -I/src/sbin/devd -fstack-protector -c /src/sbin/devd/devd.cc /src/sbin/devd/devd.cc: In member function 'virtual bool media::do_match(config)': /src/sbin/devd/devd.cc:223: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Stop in /src/sbin/devd. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-08 12:12:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-08 12:12:45 - ERROR: failed to build world TB --- 2009-10-08 12:12:45 - 2188.95 user 463.45 system 2928.93 real http://tinderbox.des.no/tinderbox-releng_8-RELENG_8-i386-pc98.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: samba - SIGABRT
On Thu, 8 Oct 2009, Oliver Lehmann wrote: This was caused by your setting of the following: security.bsd.map_at_zero=0 You can reset that value to 1 and you should be alright to operate like normal otherwise you will have to compile samba over again with the above mentioned configure options. Yeah this caused the problem. I wonder how I could have find this by myself (google is not counting ;)) I mean, the Abort message is not very verbose what the problem is here Hi Oliver-- While it's probably a bug that the Samba port compiles --pie, it's also a bug that our linking bits aren't handling PIE properly either. The goal is to fix PIE with the non-NULL mapping feature in the immediate future, so with any luck the abort message won't matter too much longer. Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: samba - SIGABRT
On Thu, 8 Oct 2009, Robert Watson wrote: On Thu, 8 Oct 2009, Oliver Lehmann wrote: This was caused by your setting of the following: security.bsd.map_at_zero=0 You can reset that value to 1 and you should be alright to operate like normal otherwise you will have to compile samba over again with the above mentioned configure options. Yeah this caused the problem. I wonder how I could have find this by myself (google is not counting ;)) I mean, the Abort message is not very verbose what the problem is here Hi Oliver-- While it's probably a bug that the Samba port compiles --pie, it's also a bug that our linking bits aren't handling PIE properly either. The goal is to fix PIE with the non-NULL mapping feature in the immediate future, so with any luck the abort message won't matter too much longer. How about reverting this change or defaulting security.bsd.map_at_zero=1 until either ports can handle this properly or our -pie is fixed, and we've had at least a release with pre-built packages that don't have the problem? -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kbdcontrol: map Backspace key to '\' fails
Claus Assmann freebsd+sta...@esmtp.org wrote:
On FreeBSD 7.2-STABLE it seems to be impossible to map the Backspace
key to '\' and '|'. Here's what I did:
Change /usr/share/syscons/keymaps/us.unix.kbd:
[...]
The diff looks good and should work fine.
and run:
kbdcontrol -k /dev/console -l /usr/share/syscons/keymaps/us.unix.kbd
That -k options doesn't make sense at all. Actually I'm
surprised that it doesn't give you an error message.
Please use this command:
kbdcontrol -l us.unix.kbd /dev/ttyv0
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
PI:
int f[9814],b,c=9814,g,i;long a=1e4,d,e,h;
main(){for(;b=c,c-=14;i=printf(%04d,e+d/a),e=d%a)
while(g=--b*2)d=h*b+a*(i?f[b]:a/5),h=d/--g,f[b]=d%g;}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openssh concerns
Doug Barton wrote: Daniel Bond wrote: However, I'm concerned about the suggestion of using an unprivileged port Please explain your reasoning, and how it's relevant in a world where the vast majority of Internet users have complete administrative control over the systems they use. There are shell machines with lots of user accounts, none of which have administrative control of the system. In fact I'm running such a machine myself. Suppose there is a security hole in sshd that enables a DoS attack, i.e. some use is able to kill the sshd daemon. Or maybe the sshd daemon dies because of some other, unrelated reason. If it was running on an unprivileged, a normal user would now be able to start up his own (probably modified) sshd daemon on the very same port. He won't have the correct host key, of course, but I can tell you that many users ignore the warning and innocently type yes when asked whether to accept the fingerprint. Probably the admin reinstalled something, this happened before, don't worry. If you run the sshd daemon on a privileged port 1024 (or one protected by mac_portacl(4)), that security problem does not exist at all. Normal users can't start up a fake daemon on such a port if the real daemon dies. Even if there are no user accounts, it's not worth taking chances. It's always possible that there will be some hole in some silly, unrelated daemon that enables remote execution ... then you have a user account without knowing. Successful attacks are often the result of two or more unrelated holes, so it's definitely worth to plug every sinlge hole, even small ones that seem unimportant. Running a critical daemon like sshd in an unprivileged port is such a hole, in my opinion. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openssh concerns
Oliver Fromme wrote: There are shell machines with lots of user accounts, none of which have administrative control of the system. Sure there are, but they make up only a tiny fraction of the systems on the network today. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openssh concerns
On Fri, Oct 9, 2009 at 12:22 AM, Doug Barton do...@freebsd.org wrote: Oliver Fromme wrote: There are shell machines with lots of user accounts, none of which have administrative control of the system. Sure there are, but they make up only a tiny fraction of the systems on the network today. shared webhost? -- O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Bug in 7.2-STABLE's /bin/sh?
On Thu, Oct 01, 2009 at 09:12:19PM +0200, Andre Albsmeier wrote: On Thu, 01-Oct-2009 at 20:31:01 +0200, Andre Albsmeier wrote: On Thu, 01-Oct-2009 at 18:44:08 +0300, Andriy Gapon wrote: on 01/10/2009 17:49 Andre Albsmeier said the following: Hello all, is it correct to print OK here? -- snip -- #!/bin/sh if false || ! echo bla | grep -q bla; then echo OK fi -- snap --- 7.2-STABLE (can't check others at the moment) does which I think is wrong... This looks like a bug and it seems to be fixed in head. Forgotten MFC? Have you got a PR# handy? Found it myself: http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/sh/parser.c.diff?r1=1.60;r2=1.61 seems to be it. Could someone please MFC that to 7.2? Thanks, Done! (to stable/7, that is) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: samba - SIGABRT
On Thu, 8 Oct 2009, Daniel Eischen wrote: While it's probably a bug that the Samba port compiles --pie, it's also a bug that our linking bits aren't handling PIE properly either. The goal is to fix PIE with the non-NULL mapping feature in the immediate future, so with any luck the abort message won't matter too much longer. How about reverting this change or defaulting security.bsd.map_at_zero=1 until either ports can handle this properly or our -pie is fixed, and we've had at least a release with pre-built packages that don't have the problem? Sorry, I should have been more clear: the problem is with run-time linking, not compile-time linking. Kostik has just posted patches for the run-time linker to current@, which should allow the existing binaries to work with map_at_zero=0. If we aren't able to get the run-time linker fixes into 8.0, we will definitely revert the default change for map_at_zero so that it is enabled. However, since there is a significant security benefit to shipping with map_at_zero disabled, I think we should try hard to ship 8.0 with a fixed rtld. Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openssh concerns
Doug Barton wrote: Oliver Fromme wrote: There are shell machines with lots of user accounts, none of which have administrative control of the system. Sure there are, but they make up only a tiny fraction of the systems on the network today. Are you sure? The majority of BSD machines in my vicinity have multiple accounts. And even if there's only one account, there is no reason to be careless with potential port-takeover risks. Therefore I advise against running critical daemons on unprivileged ports, especially on machines with shell accounts. And if you need to bind to a port = 1024, use mac_portacl(4) to protect it. It's easy to use. Alternatively you can increase the value of the sysctl net.inet.ip.portrange.reservedhigh, but this is less flexible and might have unwanted side effects. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++ is the only current language making COBOL look good. -- Bertrand Meyer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openssh concerns
Quoting Doug Barton do...@freebsd.org: Oliver Fromme wrote: There are shell machines with lots of user accounts, none of which have administrative control of the system. Sure there are, but they make up only a tiny fraction of the systems on the network today. wow Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
