Re: sockaddr_in initialization in ttcp (possibly other programs affected)
Hi, The main reason I've notified this ''bug'' to .misc is because other (important, maintained, in base? , etc) code may fail too. Cheers > -Original Message- > From: Jeremie Courreges-Anglas [mailto:j...@wxcvbn.org] > Sent: Monday, September 12, 2016 10:30 > To: Héctor Luis Gimbatti > Cc: misc@openbsd.org; Philip Guenther > Subject: Re: sockaddr_in initialization in ttcp (possibly other programs affected) > > Philip Guenther writes: > > > On Tue, 6 Sep 2016, Héctor Luis Gimbatti wrote: > >> I post this to .misc since some other (than ttcp) programs might not > >> work in recent versions of OBSD. > >> > >> In OBSD 5.6 I am able to run ttcp. > >> > >> $ uname -a > >> OpenBSD pez.etale.com.ar 5.6 GENERIC.MP#333 amd64 $ ttcp -r -s > >> ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp > >> ttcp-r: socket > >> > >> In OBSD 5.9 and 6.0 I am not able to run it (sadly I do not have > >> running machines with 5.7 nor 5.8). > > > > The change was in 5.9, with this commit to in_pcb.c: > > > > > > revision 1.178 > > date: 2015/09/11 13:59:27; author: vgross; state: Exp; lines: +3 > > -7; > > commitid: NyNuX1q0M9Dwr560; > > Stricter checks on sockaddr content when binding PF_INET sockets. > > > > Ok mpi@ > > > > > > Unless this is just the most recent in a series of similar reports, I > > doubt we'll back this out or revise the check; it's just old code, > > written in the slightly sloppy style of the time. > > > > > >> Looking at the code in ttcp.c the problem seems to be that the field > >> sin_family in the structure sockaddr_in (sinme) is not initialized. > >> > >> By adding sinme.sin_family = AF_INET; before bind(...) the program > >> works fine. > > > > No specific maintainer on the port, so I suggest you send your diff to > > po...@openbsd.org, so it can be included in ports and packages going > > forward. > > +1, misc is not for bug reports. > > Anyway, I went ahead and deleted net/ttcp. It was old, unmaintained code, and > showed scary compile-time warnings (implicit declaration of malloc for > example). For better alternatives, see tcpbench in base or net/iperf in ports. > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 > E7EE [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
sockaddr_in initialization in ttcp (possibly other programs affected)
Greetings, I post this to .misc since some other (than ttcp) programs might not work in recent versions of OBSD. In OBSD 5.6 I am able to run ttcp. $ uname -a OpenBSD pez.etale.com.ar 5.6 GENERIC.MP#333 amd64 $ ttcp -r -s ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp ttcp-r: socket In OBSD 5.9 and 6.0 I am not able to run it (sadly I do not have running machines with 5.7 nor 5.8). $ uname -a OpenBSD bsd002.vmn.etale.com.ar 6.0 GENERIC.MP#1917 i386 $ ttcp -r -s ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp ttcp-r: socket ttcp-r: bind: Address family not supported by protocol family errno=47 Looking at the code in ttcp.c the problem seems to be that the field sin_family in the structure sockaddr_in (sinme) is not initialized. By adding sinme.sin_family = AF_INET; before bind(...) the program works fine. Cheers --- HLG
Pledge: quota syscall
Greetings, Ive found that the call at line 536 of quota.c (current) causes abort when pledge is required: if(quotactl(fs->fs_file, qcmd, id, (char *)&qup->dqblk) != 0) Is it necessary to include quotactl (SYS_quotactl) in pledge in order to support basecode such as edquota, quota, etc? Thanks --- HLG
Re: /usr/sbin/dhcpd -u pledge failure.
A couple of programs are passing "route" to pledge (bgpd.c; iked.c; ...) We have to document the route syscall in pledge (2) > -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf > Of Philip Higgins > Sent: Monday, April 04, 2016 01:12 > To: misc@openbsd.org > Subject: /usr/sbin/dhcpd -u pledge failure. > > Hi, > > When using 'udpsockmode' in dhcpd (-u flag), it first calls pledge("stdio rpath > inet sendfd proc id", NULL) (in udpsock.c) > > then tries > pledge("stdio inet route sendfd", NULL) (back in dhcpd.c) > > The "route" causes it to fail. > > eg. > $ doas dhcpd -u -fd pppx0 > Listening on 255.255.255.255:67/udp. > dhcpd: pledge: Operation not permitted > > "route" isn't defined in the pledge(2) man page, but testing seems to indicate it is > necessary. > > Index: udpsock.c > = > == > RCS file: /cvs/src/usr.sbin/dhcpd/udpsock.c,v > retrieving revision 1.5 > diff -u -p -r1.5 udpsock.c > --- udpsock.c 8 Feb 2016 02:06:07 - 1.5 > +++ udpsock.c 4 Apr 2016 04:09:14 - > @@ -65,7 +65,7 @@ udpsock_startup(struct in_addr bindaddr) > error("setsocketopt IP_RECVIF failed for udp: %s", > strerror(errno)); > > - if (pledge("stdio rpath inet sendfd proc id", NULL) == -1) > + if (pledge("stdio rpath inet sendfd proc id route", NULL) == -1) > error("pledge: %s", strerror(errno)); > > sin4.sin_family = AF_INET; > > > -- > -Phil [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
mg configuration file
Greetings, I am running obsd 5.8 and stock mg. My config file ~/.mg: auto-indent-mode blink-matching-paren When I run mg without arguments the auto indent mode works as expected. But when I run mg with an argument (eg mg foo.c) auto indent doesn't work. I've got the source of mg from cvs and I've checked that the file .mg is being loaded and the 2 lines in my configuration file are readed as expected. On a side note, I've had to remove the reference to pledge in order to compile mg. Thanks --- HLG [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: sshd segfaults with incomplete /etc/hosts
On the same topic, $ man 5 hosts BUGS: Lines in /etc/hosts are limited to BUFSIZ characters (currently 1024). Longer lines will be ignored. I've made a couple of test: 1. If the line has the following pattern: 10.0.1.1 aa b c z $ getent hosts 10.0.1.1 10.0.1.1 . So it trims the line and we are on the SANE size (less than 1024) 2. By LINE its meant to be LINE WITHOUT IP. One can test this by: 10.0.1.1 aaa...a Where there are 1023 letter a. If IP is taken into account, the line has more than 1024 characteres.
vfs references to strncpy and MFSNAMELEN
The constant MFSNAMELEN as defined in: lib/libc/sys/getfsstat.2:#define MFSNAMELEN 16 lib/libc/sys/statfs.2:#define MFSNAMELEN 16 sys/sys/mount.h: #define MFSNAMELEN 16 defines the fs type name and, according to comments, it includes nul terminating character. The following code makes uses of strncpy and involves MFSNAMELEN ./sys/kern/vfs_subr.c:225: strncpy(mp->mnt_stat.f_fstypename, vfsp->vfc_name, MFSNAMELEN); ./sys/kern/vfs_subr.c:2272: strncpy(sbp->f_fstypename, mp->mnt_vfc->vfc_name, MFSNAMELEN); ./sys/kern/vfs_syscalls.c:243: strncpy(mp->mnt_stat.f_fstypename, vfsp->vfc_name, MFSNAMELEN); ./sys/miscfs/procfs/procfs_vfsops.c:190:strncpy(sbp->f_fstypename, mp->mnt_vfc->vfc_name, MFSNAMELEN); ./sys/msdosfs/msdosfs_vfsops.c:669: strncpy(sbp->f_fstypename, mp->mnt_vfc->vfc_name, MFSNAMELEN); ./sys/nfs/nfs_vfsops.c:646: strncpy(&mp->mnt_stat.f_fstypename[0], mp->mnt_vfc->vfc_name, MFSNAMELEN); ./sys/ntfs/ntfs_vfsops.c:628: strncpy(sbp->f_fstypename, mp->mnt_vfc->vfc_name, MFSNAMELEN); ./sys/ufs/ext2fs/ext2fs_vfsops.c:704: strncpy(sbp->f_fstypename, mp->mnt_vfc->vfc_name, MFSNAMELEN); ./sys/ufs/mfs/mfs_vfsops.c:222: strncpy(&sbp->f_fstypename[0], mp->mnt_vfc->vfc_name, MFSNAMELEN); Can be those replace safely by strlcpy without any modification to MFSNAMELEN constant?
support new
0 C Argentina P Santa Fe T Rosario Z 2000 I Hector Luis Gimbatti A Italia 4838 M h...@etale.com.ar N OpenBSD consulting, installation, maintenance and support for mid-size business. Over 10 years of experience with BSD based systems (both servers and clients). Experienced in firewalls and OpenBSD daemons.