From owner-freebsd-arch@freebsd.org Sun May 22 06:40:50 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33D47B43F0E; Sun, 22 May 2016 06:40:50 +0000 (UTC) (envelope-from mckusick@chez.mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:d250:99ff:fe57:4030]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "chez.mckusick.com", Issuer "chez.mckusick.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 033D21D1B; Sun, 22 May 2016 06:40:49 +0000 (UTC) (envelope-from mckusick@chez.mckusick.com) Received: from chez.mckusick.com (localhost [IPv6:::1]) by chez.mckusick.com (8.15.2/8.15.2) with ESMTP id u4M6enEo017327; Sat, 21 May 2016 23:40:49 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201605220640.u4M6enEo017327@chez.mckusick.com> From: Kirk McKusick To: Andriy Gapon Subject: Re: mount / unmount and mountcheckdirs() cc: freebsd-arch@FreeBSD.org, freebsd-fs In-reply-to: <5c01bf62-b7b2-2e1d-bca5-859e6bf1f0e5@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17325.1463899249.1@chez.mckusick.com> Content-Transfer-Encoding: quoted-printable Date: Sat, 21 May 2016 23:40:49 -0700 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2016 06:40:50 -0000 > To: freebsd-arch@FreeBSD.org, freebsd-fs > From: Andriy Gapon > Subject: mount / unmount and mountcheckdirs() > Date: Sun, 15 May 2016 16:37:05 +0300 > = > I am curious about the purpose of mountcheckdirs() called when mounting = and > unmounting a filesystem. > = > The function is described as such: > /* > * Scan all active processes and prisons to see if any of them have a cu= rrent > * or root directory of `olddp'. If so, replace them with the new mount = point. > */ > and it seems to be used to "lift" processes and jails to a root of a new > filesystem when it is mounted and to "lower" them onto a covered vnode (= if any) > when a filesystem is unmounted. > = > What's the purpose of those actions? > It's strange that the machinations are done at all, but it is stranger t= hat they > are applied only to processes and jails at exactly a covered vnode and a= root > vnode. Anything below in a filesystem's tree is left alone. Is there a= nything > so very special about being at exactly those points? > = > IMO, the machinations can have unexpected security consequences. > = > A little bit of history. > mountcheckdirs() was first added in r22521 (circa 1997) as checkdirs wit= h a > rather non-specific commit message. Initially it was used only when a > filesystem was mounted. > Then, in r73241 (circa 2002) the function was added to dounmount(): > The checkdirs() function is called at mount time to find any process > fd_cdir or fd_rdir pointers referencing the covered mountpoint > vnode. It transfers these to point at the root of the new filesystem= . > However, this process was not reversed at unmount time, so processes > with a cwd/root at a mount point would unexpectedly lose their > cwd/root following a mount-unmount cycle at that mountpoint. > ... > Dounmount() now undoes the actions > taken by checkdirs() at mount time; any process cdir/rdir pointers > that reference the root vnode of the unmounted filesystem are > transferred to the now-uncovered vnode. > = > = > -- = > Andriy Gapon I added the checkdirs functionality in the mount direction only (I actually did it in 4.4BSD-Lite and it got swept in with commit 22521). The reason is that when a directory that is not empty is mounted on, the expectation is that the entries in that directory should no longer be present; rather they should be replaced by the entries in the newly mounted directory. Thus all processes sitting in the mounted on directory should see the newly mounted directory as if they had come to it using a lookup after the mount had been done. If a process had proceeded through the mounted on directory into one of its other entries, then they are left alone until such time as they chdir back into the mount point directory through ".." at which time they will be passed up to the mounted directory using the same mechanism that would put them there if they traversed into the mount point from above it in the tree. I believe this is the correct behavior, is not a security threat, and should be left alone. I was not aware that the functionality had been added at unmount time, and I do not believe that it should have been done. Normally an unmount will not succeed if any vnodes are busy (for example, if any directory in the filesystem is a current directory). The only way that it can succeed in such a case is if a forcible unmount is done. The forcible unmount will effectively do a revoke(2) on all current directory vnodes in the unmounted filesystem. Further attempts to access them will fail with "." not found errors. The only way to get a valid current directory is to chdir to an absolute pathname. Gratuitously fixing this if you happen to be in the former root of the filesystem is wrong. And as you note can lead to unintensionally giving an escape path from a prison. So I concur with your removing this added functionality. Kirk McKusick that it can succeed if any From owner-freebsd-arch@freebsd.org Wed May 25 18:20:31 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A5BEB4992D for ; Wed, 25 May 2016 18:20:31 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5DB4F16CE for ; Wed, 25 May 2016 18:20:31 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 526881DED for ; Wed, 25 May 2016 18:20:31 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 1170019CE9 for ; Wed, 25 May 2016 18:20:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id qRvCwi8yt527 for ; Wed, 25 May 2016 18:20:28 +0000 (UTC) To: "freebsd-arch@freebsd.org" DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com E44D319CDF From: Bryan Drewery Subject: [Build] Enabling automatic object directory creation Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <5e8f0d99-dab1-36a8-1aac-328de4490145@FreeBSD.org> Date: Wed, 25 May 2016 11:20:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="blLpJKRvLJFWHeKtKg5lsfvGL9VH5vERU" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 18:20:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --blLpJKRvLJFWHeKtKg5lsfvGL9VH5vERU Content-Type: multipart/mixed; boundary="JoN8ecuKiEiJx34inKN6kJ7o4vH78GtID" From: Bryan Drewery To: "freebsd-arch@freebsd.org" Message-ID: <5e8f0d99-dab1-36a8-1aac-328de4490145@FreeBSD.org> Subject: [Build] Enabling automatic object directory creation --JoN8ecuKiEiJx34inKN6kJ7o4vH78GtID Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable For in-tree source builds only, I would like to make it so that 'make' in a subdirectory would automatically create the object directory. This would naturally extend to buildworld/buildkernel as well with some tweaks. I already am nearly done with adding this in for buildworld and was going to just make it happen since the 'make obj' tree-walk is a waste of time. It is very error-prone to not automatically create an object directory when building in a subdirectory as it may look for files in the wrong place. So I would prefer to add it everywhere instead= =2E What is the impact of this feature? Keep in mind this would *only affect in-tree builds, not ports*. We would need to move the 'default' MAKEOBJDIRPREFIX from Makefile/Makefile.inc1 into share/mk/sys.mk. It would only be overridable from environment and make argument, but also /etc/src-env.conf (I think). This restriction is already in place. I would have to move the assertion for this out of /Makefile and into sys.mk. Now when I say sys.mk I really mean something like src.sys.env.mk. which is hidden in a way to only impact in-tree builds. The feature is named 'WITH_AUTO_OBJ'. Enabling this by default means that the only way to disable it is to add WITHOUT_AUTO_OBJ=3Dyes to environment, make argument or /etc/src-env.conf. There are times when building in a directory without an object directoy makes sense, but for the vast majority of people they likely have done a buildworld already and are trying to build in a subdirectory to test something further. If they pulled down new revisions then it is possible that this new directory did not get a 'make obj' tree-walk. A side topic is changing the default MAKEOBJDIR such that it always uses ${MAKEOBJDIRPREFIX}/${SRCTOP}/${TARGET}.${TARGET_ARCH}/${RELDIR}. Doing this is far simpler if I can just use WITH_AUTO_OBJ everywhere. This is discussed a bit in https://reviews.freebsd.org/D3711. It would give directories such as: /usr/obj/usr/src/amd64.amd64/bin/sh. It would keep all universe/cross-builds inside of /usr/obj/usr/src and allow more easily cleaning up object trees with multiple checkouts. This object tree pattern is what the DIRDEPS_BUILD uses as well and has been quite handy. I would extend the DIRDEPS_BUILD 'make destroy' and 'make destroy-arch', to the normal build, to cleanup the entire object tree for the object directory and the specified target.target_arch respectivel= y. --=20 Regards, Bryan Drewery --JoN8ecuKiEiJx34inKN6kJ7o4vH78GtID-- --blLpJKRvLJFWHeKtKg5lsfvGL9VH5vERU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJXRezrAAoJEDXXcbtuRpfPK7IH/2nwXZS6/JtzUhXVOb1pExdy N+V27ILj9UiJtrWXWCYZjAtM4w1wvuNNeIySALruNiKqVndHuNSDm/j/uOQFiA1T GlGZrU/0XQ2LFVNrVSnYHI2upoJH1h9jS786zG/LMLWDFFII76sF2CP5jyVYkoWk GU4SqK3UWMR+hTQ0TYg8tuINjii1daAib7VPEfkm4u3sj6GNA6RTl8Dfy+j/BgKD hjw0fR2x1Q2I//G8TguRWea/w47RHX4GQI3ZAxBqNQK1qN2kZd027+v1eLgyESaV E/k7rKLZV8by2GaBKAg8//m2fRTqQeKJv3bK5lcGJsOEIYOSpYJ+vUC0DAoaJjw= =62Zf -----END PGP SIGNATURE----- --blLpJKRvLJFWHeKtKg5lsfvGL9VH5vERU-- From owner-freebsd-arch@freebsd.org Wed May 25 21:14:11 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9DE18B4AC7D for ; Wed, 25 May 2016 21:14:11 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8073818B5 for ; Wed, 25 May 2016 21:14:11 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u4PLE1NA007337; Wed, 25 May 2016 14:14:07 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201605252114.u4PLE1NA007337@gw.catspoiler.org> Date: Wed, 25 May 2016 14:14:01 -0700 (PDT) From: Don Lewis Subject: Re: is ut_user[] in struct utmpx NUL terminated? To: ed@nuxi.nl cc: freebsd-arch@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 21:14:11 -0000 On 16 May, Ed Schouten wrote: > Hi Don, > > 2016-05-16 1:07 GMT+02:00 Don Lewis : >> There is a lot of code that expects ut_user[] to be NUL terminated. > > Our implementation of utmpx should be pretty friendly to use: > > - You can call pututxline() with strings that are not null terminated. > - The getutx*() functions return entries in which all strings are null > terminated. The latter doesn't appear to be true. If I stuff a non-NUL terminated 32 character user name into ut_user and then call pututxline(), it calls utx_to_futx(), which uses the UTOF_STRING() macro, which in turn uses snprintf() to copy the data to the corresponding field in a struct futx before saving the latter. Going in the other direction, getutxent() calls futx_to_utx(), which uses the FTOU_STRING() macro, which in turn uses strncpy() to copy the data back out. If the original name was 32 characters, then the ut_user value in the returned struct utmpx will not be NUL terminated. From owner-freebsd-arch@freebsd.org Wed May 25 21:26:04 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92A3DB4ADFE for ; Wed, 25 May 2016 21:26:04 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 60E251CD6 for ; Wed, 25 May 2016 21:26:04 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-it0-x229.google.com with SMTP id z189so71450753itg.0 for ; Wed, 25 May 2016 14:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=2ffgCJVE5+Uuqtgj/Y7Fq/FawQS7mkN3CvDOA5uGXDs=; b=BgVObw8sgJwpP4bYM06tXu8niuINyIrRypqMGiB0gd5WmrnsQrfqnD6VWL6UBldRem mjaY1zoDMEN8IXJtxvso9tcdTVLU7HSf7yIoJC66TPoY2IT+iPrVJwLfqC/m3Bl2xxPa 2xchFkhAEZaLTHycQwfzS5K5P3aWMQd8XR9nqVok7WNLuZe1amYsP/FG5yzy1fzXomDX rtQs4xwioSZnr96/v7AkLIQJK6KG7cUiFYGLRzy3TzIefdYDUbJZ6fasxN0fb5J4c6Or rO6HgElvesHtp8/HGKJUZup4K+m9ni60cf1v+2KsfzANObwxGlkaIWvTXZEuiKLbKAws PeyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2ffgCJVE5+Uuqtgj/Y7Fq/FawQS7mkN3CvDOA5uGXDs=; b=Ssi7eiB3ZnESpmtsheYR98yAjd6nKVFuYtvTy46OmMS6D4rqECDmjxnhRW7bVfvC+q HMcz/XSyAyICY9A400X7VuUMFa4NXeJ9xr4syjPW0CdX1XFsIefiejqTDxiTAutPaDYp wfNsYjmg+ESFMzsIG182GdXWAR2amrYtAGeQ6gGUaebG/3cklBWJa3XYaX/o4oePOk/Z hnXkg5AJhf19BAvDc45jNhxzwCpcQh9GhswprXAAJHOv5Pt6W2hBH9+RWhybJtkRmOPj Jq06VOCkBxHpZ2zGGIkSF/5G45tbvDnzNEm3Tx1w81xHkVh9FmvMKi6LeBHP/OEGHpRd qDxA== X-Gm-Message-State: ALyK8tKqprusi4yIHlAkZKAFuhCSNwiWT/EHp9smROtW/ZgDnTrhYe64ZsVHChnJMhBVInBBIl7PKe+ihCB/tw== MIME-Version: 1.0 X-Received: by 10.129.56.68 with SMTP id f65mr3878139ywa.240.1464211563395; Wed, 25 May 2016 14:26:03 -0700 (PDT) Received: by 10.13.201.199 with HTTP; Wed, 25 May 2016 14:26:03 -0700 (PDT) In-Reply-To: <201605252114.u4PLE1NA007337@gw.catspoiler.org> References: <201605252114.u4PLE1NA007337@gw.catspoiler.org> Date: Wed, 25 May 2016 23:26:03 +0200 Message-ID: Subject: Re: is ut_user[] in struct utmpx NUL terminated? From: Ed Schouten To: Don Lewis Cc: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 21:26:04 -0000 Hi Don, 2016-05-25 23:14 GMT+02:00 Don Lewis : > Going in the other direction, getutxent() > calls futx_to_utx(), which uses the FTOU_STRING() macro, which in turn > uses strncpy() to copy the data back out. Keep in mind that strcpy() is called with a size that is at most one less than sizeof(ut->ut_user). The final byte in the array is never overwritten. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 From owner-freebsd-arch@freebsd.org Wed May 25 21:26:50 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61736B4AE78 for ; Wed, 25 May 2016 21:26:50 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D9B31E35 for ; Wed, 25 May 2016 21:26:50 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-ig0-x22d.google.com with SMTP id ww4so79461423igb.1 for ; Wed, 25 May 2016 14:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=UekSu7Oja5wZuGC2Q66x2sda4U/bdgGVT/PcQ69lD2k=; b=EtpKYshkE1KLPTo8hPjUdDsh3+At42b9OvdmQb5vxYyP+N5c19GBOpej2EX8Hx29Zi wnXnvPKrnvObRJc+JD/9BAVGsydRk5Cpr0O4x6H8dNyU5rfTFJsb+Ob9CfoJy74lkJEU kk7I/n8x4CJbUVXdU9inxaythY5ItkMgZtd5xr5HHBpnDIPzLx6iQYm7tLkAt/N7/oPL IAGwAS/ezkZW8aod9f/+PC3fm06EGJ4a6rVvgXnuLsHbkBKyBf0ivTJQJQITJLQSxwUf 0qRYa5X8qIqO+kaac6205xKl5RHm93vFAqZ7eBjL+ulmpZUCrrEZQfcN9+Y3y3vlOcYM T3bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=UekSu7Oja5wZuGC2Q66x2sda4U/bdgGVT/PcQ69lD2k=; b=GWRrs9E8kjDkjtrf8MuQMv426Mjgo/ZzdbqU3koq4+VWT+f5JD+hhcO2EQby4pPPgY Hz+wA8Kx/lpTPmclu1nw6LD3htNTx9wGgF6RtEvDvJhGb7i1F+qx5AQ24tzEpxQRAJ71 0WmDOKufhtSDcabtGMGI41g7KuKZmf6hL6AO77bDF2WDlkbRzb8hBB27BQ4+ltHvTwLV HEcTt/bImgKd6267k1qxu7quFPlRJ6E75YamHnRzIKydfS0lufsM3L/CWBMKKSfpCU3r UNDCDIWvU8PEm52+LWpwDleFcGuPr7xJS0m+cQE43lW2dhCBGRwvYRWLbG+onhDE3zFa CGiA== X-Gm-Message-State: ALyK8tLR6ecniOckYdUONXNb3/Am15/eqM3VQX2xhbZOIyp5kTgOGhhG+X4/mkUOfTUO0VGtQMIbVE6qvpc0yw== MIME-Version: 1.0 X-Received: by 10.129.162.141 with SMTP id z135mr3801999ywg.50.1464211609556; Wed, 25 May 2016 14:26:49 -0700 (PDT) Received: by 10.13.201.199 with HTTP; Wed, 25 May 2016 14:26:49 -0700 (PDT) In-Reply-To: References: <201605252114.u4PLE1NA007337@gw.catspoiler.org> Date: Wed, 25 May 2016 23:26:49 +0200 Message-ID: Subject: Re: is ut_user[] in struct utmpx NUL terminated? From: Ed Schouten To: Don Lewis Cc: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 21:26:50 -0000 2016-05-25 23:26 GMT+02:00 Ed Schouten : > Keep in mind that strcpy() is called with a size that is at most one > less than sizeof(ut->ut_user). The final byte in the array is never > overwritten. Sorry; strncpy() of course. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 From owner-freebsd-arch@freebsd.org Wed May 25 21:49:46 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD6C1B4A3AE for ; Wed, 25 May 2016 21:49:46 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 875321A45 for ; Wed, 25 May 2016 21:49:46 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u4PLnaoG007496; Wed, 25 May 2016 14:49:40 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201605252149.u4PLnaoG007496@gw.catspoiler.org> Date: Wed, 25 May 2016 14:49:36 -0700 (PDT) From: Don Lewis Subject: Re: is ut_user[] in struct utmpx NUL terminated? To: ed@nuxi.nl cc: freebsd-arch@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 21:49:46 -0000 On 25 May, Ed Schouten wrote: > Hi Don, > > 2016-05-25 23:14 GMT+02:00 Don Lewis : >> Going in the other direction, getutxent() >> calls futx_to_utx(), which uses the FTOU_STRING() macro, which in turn >> uses strncpy() to copy the data back out. > > Keep in mind that strcpy() is called with a size that is at most one > less than sizeof(ut->ut_user). The final byte in the array is never > overwritten. It looks like it is using sizeof() and not sizeof()-1 in both directions: Ah, it's using sizeof() going in, but I now see that there is a carefully hidden -1 adjustment coming out: #define FTOU_STRING(fu, ut, field) do { \ strncpy((ut)->ut_ ## field, (fu)->fu_ ## field, \ MIN(sizeof (ut)->ut_ ## field - 1, sizeof (fu)->fu_ ## field)); \ } while (0) We should probably document this in the man page. The Linux man page that I found online says that the string fields are NUL terminated only if there is room. The Mac OS X man page and Open Group documentation are silent on this, which would lead one to think these fields are NUL terminated. Code also has be careful to not make the assumption that these fields are NUL terminated if the struct utmpx has not been laundered through pututxline() and getutx*(), though this should be rare. From owner-freebsd-arch@freebsd.org Thu May 26 06:30:35 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9461B4AF93 for ; Thu, 26 May 2016 06:30:35 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB9BA11C7 for ; Thu, 26 May 2016 06:30:35 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-yw0-x22b.google.com with SMTP id c127so68040688ywb.1 for ; Wed, 25 May 2016 23:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=S2pASZAoE98s+nazjRm41IVTDCjdYrkCC7DPv2dfuQ0=; b=jR5FRfBg6PdB/bs5boNoPTcMMRIFWdL7/p8XynVZG7AqPzIoL0tN87k2wiChRj9fmT 9HEgewF3ZW1EJ4cXAvzVC+FM/QiDDNZqPjQQ3i1WLxxylkmzjn+GqsW1AN3sqcAWL2cn kDYVerlU91lmLVTrDyTUJkzeStGy2M6u5NPwIGHT1sf6Z6gVYmfjE4hb5eAGNK3jn3lu W3KeAKcKaIMrJPyzFAxQRy8uyKh0SGZAxHmeop6wvqel8Y7bhuOdJa9ERGOzsX4Z0zzy cr+F6QXzKriRnL3LYVflceEYBDjKfzTTKjXcX11NMHdE1T87jil2Xe9iD2KqiseUNc7v Xjzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=S2pASZAoE98s+nazjRm41IVTDCjdYrkCC7DPv2dfuQ0=; b=WajvQFXi3b37VjDiwZ+6GSeTE5/CSCj6y6nAQPnsvzUx3umtwR1rqiDwM18dRj596c RpY7G+siKDdteJdq8yk+QQ3kv7XIkNEZqLGsT/aFVerGeZ3l0bP/k2UlCQ//amxsF4LL k+BOsIhfePOnDepCmFMCA54LaH8tedUmc20e+RUoT8eEUQ484HWI5QjWYy28ujZscSlF GK2SKI90g5NTJ+kNjpBpcEDdLS4wan0DCb1U0Sh1WCTlku6q3B50WmYVkxr1KrCA7u34 S9jhgla25r0cUxL5CAZMRydFY3wxrkURFu+FphaXn0WFvB6I2FHI2yHo5AMe1djL3ARS AyTQ== X-Gm-Message-State: ALyK8tLtE2WO5lCxV6j5ggNKl8MKjFLCfZqn0mKFE3mmwON+5LKE9fZtay7GNPx2j5AnAeExo8zJAVTEPrFisA== MIME-Version: 1.0 X-Received: by 10.129.162.141 with SMTP id z135mr4700940ywg.50.1464244234372; Wed, 25 May 2016 23:30:34 -0700 (PDT) Received: by 10.13.201.199 with HTTP; Wed, 25 May 2016 23:30:34 -0700 (PDT) In-Reply-To: <201605252149.u4PLnaoG007496@gw.catspoiler.org> References: <201605252149.u4PLnaoG007496@gw.catspoiler.org> Date: Thu, 26 May 2016 08:30:34 +0200 Message-ID: Subject: Re: is ut_user[] in struct utmpx NUL terminated? From: Ed Schouten To: Don Lewis Cc: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 06:30:36 -0000 2016-05-25 23:49 GMT+02:00 Don Lewis : > We should probably document this in the man page. This specific aspect is already documented in the man page: The ut_user, ut_line and ut_host fields of the structure returned by the library functions are also guaranteed to be null-terminated in this implementation. Be sure to send me a code review if you can think of ways to improve the man page. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717