From nobody Mon Aug 23 10:02:39 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B317A178E940 for ; Mon, 23 Aug 2021 10:02:50 +0000 (UTC) (envelope-from antranigv@freebsd.am) Received: from evncert.am (evncert.am [212.42.214.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GtSV12qk4z4dPM for ; Mon, 23 Aug 2021 10:02:49 +0000 (UTC) (envelope-from antranigv@freebsd.am) Received: from evncert.am (localhost [127.0.0.1]) by evncert.am (OpenSMTPD) with ESMTP id 04d79536 for ; Mon, 23 Aug 2021 14:13:37 +0400 (+04) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=freebsd.am; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:to; s=selector0; bh=6S95m0v/vKOy6BgYlrzgE43G4lo =; b=NhKWpZPJsLA/4o2SquPFT0LsPiLbCKD3vURgU2r7RL43WvQx2uKsFsj2gJY 58+xlvfDfP+KJXmPMqlwUcIw/Pm84BKvB4t2TEC/7vtwS06XyoV4Xpvx1nnEA7bp HghMxk2KS94BlT0w1/gW8Hh9+tHvJQdpmBONP+w+USOniB1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=freebsd.am; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:to; q=dns; s=selector0; b=PyA6gZfxxRM1mEhWDudIW oXflJnnpGvd/9/Eq41uqONnPka8ic+yy56E5o0i0QZVMPDDSAR0+VoT3UfOsDiTE HbzdmfMVIUpFbL2Ok1StfwTm+Y47By74HtT5v6NnGaU5U+AmEMVZFug/Oj9j9/Kc RLGjIiLBDjuYNcxhOiYJys= Received: by post.evncert.am (OpenSMTPD) with ESMTPSA id ccd7a481 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO) for ; Mon, 23 Aug 2021 14:13:37 +0400 (+04) From: antranigv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Need advice: Better Jail integration into ps/top, setpwfile gone forever? Message-Id: <1B45F065-DC9D-40C9-958F-7D4D64DE8993@freebsd.am> Date: Mon, 23 Aug 2021 14:02:39 +0400 To: "freebsd-hackers@FreeBSD.org" X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4GtSV12qk4z4dPM X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=freebsd.am header.s=selector0 header.b=NhKWpZPJ; dmarc=pass (policy=none) header.from=freebsd.am; spf=pass (mx1.freebsd.org: domain of antranigv@freebsd.am designates 212.42.214.164 as permitted sender) smtp.mailfrom=antranigv@freebsd.am X-Spamd-Result: default: False [-2.30 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; R_SPF_ALLOW(-0.20)[+mx]; DKIM_TRACE(0.00)[freebsd.am:~]; DMARC_POLICY_ALLOW(-0.50)[freebsd.am,none]; NEURAL_HAM_SHORT(-1.00)[-0.999]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_DKIM_PERMFAIL(0.00)[freebsd.am:s=selector0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:49800, ipnet:212.42.192.0/19, country:AM]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Greetings all, I am trying to have better integration of top(1) and ps(1) with FreeBSD = Jails. The main problem that I am trying to solve is displaying the correct UID = username. Here's an example. I have a host (srv0), it is running a Jail named "fsoc", The Jail "fsoc" = has a user named "romero" with the UID 1001. If I run `ps auxd` in the Jail, I get the following, romero@fsoc:~ $ ps auxd USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 4377 0.0 0.0 11376 956 - SsJ 14:15 0:00.38 = /usr/sbin/syslogd -ss root 5758 0.0 0.1 13128 1352 1 IJ 18:24 0:00.02 /bin/tcsh -i root 5763 0.0 0.0 12048 960 1 IJ 18:24 0:00.01 - su - romero romero 5764 0.0 0.1 12120 2268 1 SJ 18:24 0:00.02 `-- -su (sh) romero 9625 0.0 0.1 11684 2576 1 R+J 09:41 0:00.01 `-- ps auxd Good! However, if I try to run it on the host, here's what I get, root@srv0:~ # ps auxd -J fsoc USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 4377 0.0 0.0 11376 956 - SsJ 14:15 0:00.38 = /usr/sbin/syslogd -ss root 5758 0.0 0.1 13128 1352 1 IJ 18:24 0:00.02 /bin/tcsh -i root 5763 0.0 0.0 12048 960 1 IJ 18:24 0:00.01 - su - romero 1001 5764 0.0 0.1 12124 2436 1 I+J 18:24 0:00.02 `-- -su (sh) As you can see, in the User field it says 1001, because the host does = not have a user with that UID. This seems fine, but it becomes an issue when you have multiple Jail and = a large host running. Here's an example if the host had a user with UID 1001, root@pingvinashen:~ # ps auxd -J oragir USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 949 0.0 0.0 11344 2584 - IsJ Mon19 0:01.13 = /usr/sbin/cron -s root 1962 0.0 0.0 11428 2796 - SsJ Mon19 0:01.83 = /usr/sbin/syslogd -ss antranigv 95342 0.0 0.0 11004 2424 - IsJ Mon19 0:00.48 daemon: = /usr/home/oragir/writefreely/writefreely[9992] (daemon) antranigv 9992 0.0 0.4 767244 58336 - IJ Mon19 2:58.87 - = /usr/home/oragir/writefreely/writefreely Now, you would think that this is good, however, if you run this in the = jail, root@oragir:~ # ps auxd USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 949 0.0 0.0 11344 2584 - SsJ Mon15 0:01.13 = /usr/sbin/cron -s root 1962 0.0 0.0 11428 2796 - SsJ Mon15 0:01.83 = /usr/sbin/syslogd -ss oragir 95342 0.0 0.0 11004 2424 - IsJ Mon15 0:00.48 daemon: = /usr/home/oragir/writefreely/writefreely[9992] (daemon) oragir 9992 0.0 0.4 767244 58336 - IJ Mon15 2:58.88 - = /usr/home/oragir/writefreely/writefreely root 88228 0.0 0.0 13336 4004 8 SJ 09:45 0:00.01 /bin/csh = -i root 99502 0.0 0.0 11824 3140 8 R+J 09:45 0:00.00 - ps auxd As you can see, the UID 1001 was not `antranigv`, instead it was = `oragir`. This has been an issue for me, so I tried writing some code to implement = the following. If the process is in a Jail, then change the passwd db from /etc to = /path/of/the/jail/etc. I thought it would be an easy thing to do, but not so much. Here's what I've tried. 1) Call jail_attach and run ps inside the Jail. Oh yeah, it's a jail! = after attaching to it there is no way to deattach :-) silly me! 2) Change the passwd file for getpwuid/getpwnam. I wanted to use = setpwfile(3) but turns out that \ COMPATIBILITY The historic function setpwfile(3), which allowed the specification = of alternate password databases, has been deprecated and is no longer available. Okay, So I look into how other tools like pwd_mkdb is written and I see = that everything is defined (pun intended) the following way, in /usr/include/pwd.h #define _PATH_PWD "/etc" #define _PATH_PASSWD "/etc/passwd" #define _PASSWD "passwd" #define _PATH_MASTERPASSWD "/etc/master.passwd" #define _MASTERPASSWD "master.passwd" #define _PATH_MP_DB "/etc/pwd.db" #define _MP_DB "pwd.db" #define _PATH_SMP_DB "/etc/spwd.db" #define _SMP_DB "spwd.db" #define _PATH_PWD_MKDB "/usr/sbin/pwd_mkdb" and pwd_mkdb does the following ... strcpy(prefix, _PATH_PWD); ... case 'd': dflag++; strlcpy(prefix, optarg, sizeof(prefix)); break; ... Tuns out it parses the DB file, but I don't want to do that in ps/top! = :-) 3) Just for fun, I played with chroot. I tried the following code. # cat getpw.c=20 #define MAXHOSTNAMELEN 255 #define MAXPATHLEN 255 #include //#include #include #include #include #include #include #include int main(){ // Just get root! struct passwd *pwd; printf("just root: %s\n", (getpwuid(0))->pw_name); // let's try with undef/define #undef _PATH_PWD =20 #undef _PATH_PASSWD =20 #undef _PASSWD =20 #undef _PATH_MASTERPASSWD #undef _MASTERPASSWD =20 #undef _PATH_MP_DB =20 #undef _MP_DB =20 #undef _PATH_SMP_DB =20 #undef _SMP_DB =20 #define _PATH_PWD "/zdata/jails/fsoc/etc" #define _PATH_PASSWD "/zdata/jails/fsoc/etc/passwd" #define _PASSWD "passwd" #define _PATH_MASTERPASSWD "/zdata/jails/fsoc/etc/master.passwd" #define _MASTERPASSWD "master.passwd" #define _PATH_MP_DB "/zdata/jails/fsoc/etc/pwd.db" #define _MP_DB "pwd.db" #define _PATH_SMP_DB "/zdata/jails/fsoc/etc/spwd.db" #define _SMP_DB "spwd.db" pwd =3D getpwuid(1001); if (pwd =3D=3D NULL) { printf("using undef/define: no user found\n"); } else { printf("using undef/define: %s\n", pwd->pw_name); } // let's try with chroot! chroot("/zdata/jails/fsoc"); pwd =3D getpwuid(1001); if (pwd =3D=3D NULL) { printf("after chroot: no user found\n"); } else { printf("after chroot: %s\n", pwd->pw_name); } // escape back the chroot ;-) chroot("../../../../"); pwd =3D getpwuid(1001); if (pwd =3D=3D NULL) { printf("after unchroot: no user found\n"); } else { printf("after chroot: %s\n", pwd->pw_name); } return 42; } And I get the following: # ./getpw=20 just root: root using undef/define: no user found after chroot: romero after unchroot: no user found So, any advice? should I do chroot in ps? (no I don't think that's a = good idea), should I add a new call that implements setpwfile(3)? But I = really want to know why it was removed, I'm sure there's a story there. = Or is there a better way? Kind regards, have a nice day! -- antranigv https://antranigv.am/ From nobody Mon Aug 23 12:04:49 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6B9541777A4B for ; Mon, 23 Aug 2021 12:04:59 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GtWBy2xBJz58xV; Mon, 23 Aug 2021 12:04:58 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-lj1-x22b.google.com with SMTP id q21so31037091ljj.6; Mon, 23 Aug 2021 05:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oE7F/pmLVdPW6Kss7G1myKGx46vWPSP6E/UNtsRt16o=; b=Gn3TkNwrXo17jz1LDoSsIIqg5UVd4qkgRYsiGbo3fCn0uFQwehcGAvNlOL79leNuUG a+H6jCkR3HedpiPSVZzp9Y3AyXLolv+pP8leQoj/fEuWDk4UWKbt8EjkTnLho+uhcyDV ll4uA2jiQX4/HhyMPURU/FUyzeF4I39K9Z+MAVlp8q6uRnI7HRvbM+CWhbD77Iuh6I3G OQsU1+72dRDtmgJvFMoXlmmrwarMdMt5Zd7qZCTDMHbBBxL+IZ4mTzcJ5VTw6wCt2xND KdRcvI5/1rm+uhIJ1oFD41y6F7a0xVb/z1Osjm/NMqBshFwDfePdKKh0LoczcGULsBmi MaIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oE7F/pmLVdPW6Kss7G1myKGx46vWPSP6E/UNtsRt16o=; b=G6VmBaUCsO8lnzqo6oXjoBQMJbN8ItEvqlhyiTQPnQv3tFgzWrY4nKqUY0l15BBbZ6 c0eNvMPg1XWBnBVEPtafZMfS0P40d3cTbKWMY04/g9DOuVHwMksiUW/RzSLD+toTsITy 0730ShpFfQs9mzKXV/D7fnfvp0vipjefffNIvY3RGsYOU6uN1NW6f4mrKHQk2MXi8urJ MrviEgkhWHKU1NaUHXzy1AURO7QIqg/l2rI9/oUgHnSElHy6MRinw+5fh1StotC+Yhmh Ul4aKhNg6uwE3PmLknyl5vawZexTx0CfwjcOR3No2SEz3vvjc5Q1XkPHzO1aP7Yyrs6L 5mFw== X-Gm-Message-State: AOAM530KdnRtG5K2T33EWRyZp7leLv9aUflPp/pB1W1ocdjGb6yi2LyU 2xRJLgv8L78d5qMaqWaygiCjvv/NcEwa7nI5DeQQMyD8 X-Google-Smtp-Source: ABdhPJyJI18q4B8OUxZuMvoS1mj8pxkxiDumBrCzNAdkvhGBtOcg87npEFUP90iZxeMRUalbYttsVUNj601PzypY/uw= X-Received: by 2002:a2e:9b0b:: with SMTP id u11mr27058337lji.463.1629720290890; Mon, 23 Aug 2021 05:04:50 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a2e:6f04:0:0:0:0:0 with HTTP; Mon, 23 Aug 2021 05:04:49 -0700 (PDT) In-Reply-To: References: From: Mateusz Guzik Date: Mon, 23 Aug 2021 14:04:49 +0200 Message-ID: Subject: Re: sysctl is too slow To: Alan Somers Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4GtWBy2xBJz58xV X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Gn3TkNwr; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::22b as permitted sender) smtp.mailfrom=mjguzik@gmail.com X-Spamd-Result: default: False [0.86 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::22b:from]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-0.14)[-0.144]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N So is this something you plan on fixing? On 8/17/21, Alan Somers wrote: > Actually, I did get a flamegraph, and only 0.77% of samples were in ZFS. > > On Mon, Aug 16, 2021 at 7:19 PM Mateusz Guzik wrote: > >> On 8/16/21, Alan Somers wrote: >> > Yes, I see what you're talking about now. There are a bunch of linked >> > lists in sysctl_find_oid etc. Good point. >> > -Alan >> > >> >> You still want to get a flamegraph, chances are most of the problem is in >> zfs. >> >> > On Mon, Aug 16, 2021 at 1:30 PM Mateusz Guzik >> > wrote: >> > >> >> Last time I checked lookup of a sysctl was very bad with linear scans >> all >> >> over. >> >> >> >> Short of complete revamp of the entire thing I would start with >> >> replacing the scans with a RB tree at each level. As is if you indeed >> >> have 5000 datasets, you are doing increasingly longer walks. >> >> >> >> On 8/16/21, Alan Somers wrote: >> >> > ztop feels very sluggish on a server with 5000 ZFS datasets. Dtrace >> >> shows >> >> > that almost all of its time is spent in sys_sysctl. ktrace shows >> >> > that >> >> both >> >> > ztop and sysctl(8) call sys_sysctl a total of five times for each >> >> > sysctl >> >> > they care about: >> >> > >> >> > 1) To get the next oid >> >> > 2) To get the sysctl's name >> >> > 3) To get the oidfmt >> >> > 4) To get the size of the value >> >> > 5) To get the value itself. >> >> > >> >> > Each of these steps takes about equal time, and together all five >> >> > take >> >> > about 100us. If the time per call is mostly syscall overhead, then >> the >> >> > process could be sped up by 80% by combining all of these things >> >> > into >> a >> >> > single syscall: return the next oid, its name, its format, the size >> >> > of >> >> its >> >> > value, and optimistically the value itself, assuming the user passed >> >> > a >> >> > sufficiently large buffer. >> >> > >> >> > Am I missing something? Is there any other reason why sysctl is so >> >> > slow? >> >> > Or should I forget about it, and try to export ZFS's dataset stats >> >> through >> >> > devstat instead? >> >> > -Alan >> >> > >> >> >> >> >> >> -- >> >> Mateusz Guzik >> >> >> > >> >> >> -- >> Mateusz Guzik >> > -- Mateusz Guzik From nobody Mon Aug 23 12:54:31 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C1C701792A4A for ; Mon, 23 Aug 2021 12:54:49 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GtXJT4wkBz3Q1m for ; Mon, 23 Aug 2021 12:54:49 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f54.google.com with SMTP id i3-20020a056830210300b0051af5666070so26251381otc.4 for ; Mon, 23 Aug 2021 05:54:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8HYQ/5M+ObmLu3/zNasTiE6eIgfOIwfCZFl0FPOBHrA=; b=KoX07xB/BaFn9sdKKlMOE06BGkQPdAid9IXaB5T3LSY9WwnaeEG0Hk+CvTW2cfKchy PxrKj1LJebmEygsJBbnkMUunuiedTyt5V2L2tSAGFlhiw2/NbCKi43TYHL69euztsmag 4pAUTn5sdw2rTydXSBDTaP5weo/fTSDAj0CZXy/Y7nRLqNcX0cvB3vAyH3WpvufYnNog mhaiY5JBczIkGAvCU+KjpZZ0PtJ095jbP+mviQqqVJpgELnoQpDYC3q+S/utJhRj3SkT Yhyz2QubcbK6mGv5RYgTQN/2sRJG77U2zSdQXk2bDPdNW19zdCHeJ5ql8mCc9NPIOqdq slUA== X-Gm-Message-State: AOAM532Pf2HEOD/qVl5nSZwaBCtvsVfgzWVDpvsMlAgviuJn4MkGo4g1 4ZmXk4mbXJjhMmnrL3cfRzDlp5+ElJqyijcZnXk= X-Google-Smtp-Source: ABdhPJwjrcZB4WDC7sRB3K6mzZcWRn0O2T27fYT4Ry1PdbLpaBmtM51PviGY85MbwUtEj+DfQucYMpOmSCTB9WAeTNg= X-Received: by 2002:a05:6808:14d6:: with SMTP id f22mr11333121oiw.57.1629723282777; Mon, 23 Aug 2021 05:54:42 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Mon, 23 Aug 2021 06:54:31 -0600 Message-ID: Subject: Re: sysctl is too slow To: Mateusz Guzik Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000005a288805ca398581" X-Rspamd-Queue-Id: 4GtXJT4wkBz3Q1m X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000005a288805ca398581 Content-Type: text/plain; charset="UTF-8" Ideally, but it's not very high priority, since it's merely a performance issue in a monitoring tool. On Mon, Aug 23, 2021 at 6:05 AM Mateusz Guzik wrote: > So is this something you plan on fixing? > > On 8/17/21, Alan Somers wrote: > > Actually, I did get a flamegraph, and only 0.77% of samples were in ZFS. > > > > On Mon, Aug 16, 2021 at 7:19 PM Mateusz Guzik wrote: > > > >> On 8/16/21, Alan Somers wrote: > >> > Yes, I see what you're talking about now. There are a bunch of linked > >> > lists in sysctl_find_oid etc. Good point. > >> > -Alan > >> > > >> > >> You still want to get a flamegraph, chances are most of the problem is > in > >> zfs. > >> > >> > On Mon, Aug 16, 2021 at 1:30 PM Mateusz Guzik > >> > wrote: > >> > > >> >> Last time I checked lookup of a sysctl was very bad with linear scans > >> all > >> >> over. > >> >> > >> >> Short of complete revamp of the entire thing I would start with > >> >> replacing the scans with a RB tree at each level. As is if you indeed > >> >> have 5000 datasets, you are doing increasingly longer walks. > >> >> > >> >> On 8/16/21, Alan Somers wrote: > >> >> > ztop feels very sluggish on a server with 5000 ZFS datasets. > Dtrace > >> >> shows > >> >> > that almost all of its time is spent in sys_sysctl. ktrace shows > >> >> > that > >> >> both > >> >> > ztop and sysctl(8) call sys_sysctl a total of five times for each > >> >> > sysctl > >> >> > they care about: > >> >> > > >> >> > 1) To get the next oid > >> >> > 2) To get the sysctl's name > >> >> > 3) To get the oidfmt > >> >> > 4) To get the size of the value > >> >> > 5) To get the value itself. > >> >> > > >> >> > Each of these steps takes about equal time, and together all five > >> >> > take > >> >> > about 100us. If the time per call is mostly syscall overhead, then > >> the > >> >> > process could be sped up by 80% by combining all of these things > >> >> > into > >> a > >> >> > single syscall: return the next oid, its name, its format, the size > >> >> > of > >> >> its > >> >> > value, and optimistically the value itself, assuming the user > passed > >> >> > a > >> >> > sufficiently large buffer. > >> >> > > >> >> > Am I missing something? Is there any other reason why sysctl is so > >> >> > slow? > >> >> > Or should I forget about it, and try to export ZFS's dataset stats > >> >> through > >> >> > devstat instead? > >> >> > -Alan > >> >> > > >> >> > >> >> > >> >> -- > >> >> Mateusz Guzik > >> >> > >> > > >> > >> > >> -- > >> Mateusz Guzik > >> > > > > > -- > Mateusz Guzik > --0000000000005a288805ca398581-- From nobody Mon Aug 23 15:28:58 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 26D781789E1F; Mon, 23 Aug 2021 15:29:11 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GtbkZ4DR4z4tdK; Mon, 23 Aug 2021 15:29:10 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-ej1-x630.google.com with SMTP id a25so11160803ejv.6; Mon, 23 Aug 2021 08:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rIgzQ/kuHbZFyilLMxv8E8/vTw325c/WKNOxDKHmLQA=; b=Y2nTOvybXi7yFXZoAlWErECdWl9szhSFjNH+PAIixGcSVmdI72vg8Rn6uyYxkp1IEi 0XdLV8HZrV/8ERMXEmrd+R+EzFK/Up4E1e+wPw+0wa3rXCpkQoknjjjQUZ3y650FcbH2 pKjzA0zfyBlvgQRWtzt3IU4w2lXmTdnlkxR/TqiEglGkZl1T4z5XaXAcomo7ilXIvlvv YzDFd7Qzg+K+a2wCKQjYLESHCg8LjXAM4hKaPXcXA5BQFQ7vnrrXT8qJ5FpzIiYa+6Zi IkHevygczyOJrNBEeuiO62F+jm4yIUhyC7r9xpVaNzBw69EUT1Lg8Eof4FhOvyoP63YC AU0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rIgzQ/kuHbZFyilLMxv8E8/vTw325c/WKNOxDKHmLQA=; b=fhPUeOomuSCjebkFgx+YlRR6G8JQOs82lBLe3Az+i7ZlUU+655LVVIy0auTiWpdSN/ GZwERxjCaLmQd3GEAzLp2Mxz8jC/yUZmrbJk1ZR0HwXz92rZjdS0v9EPKf6aVh+H9tk3 dWY287BkI4CAlhvQZclrWUMlmvIqKTnvmpbAWoUtbM893FiHzAUchiK4vL+vOHWyL9vd k+ltptueIGMLtaXT46dzKNm0lItRRSyUeNIsUQhGkTTYvjlJvWDfYHuuRwya//Gw4ppV etg5UacJabBNLkWAdJJj3VWCExWlxs9uDPDSf/ZmVehaKLnrWRNzMkLwN93GIBpQE++B CEDQ== X-Gm-Message-State: AOAM531egOrWV9k4yA1OcslMjUtSJUiu6PBuqmbW3JZOkYAQqkSQ71xE 014ljhWdtyuExx98qXUPn9WZ6+galoZXrLO7nKo= X-Google-Smtp-Source: ABdhPJwlEAUC3/7vx1v/pN/KtiQ5e8GEtUwrHS4zm9KM70gnXfK/s9NcBv9xpM3B9nXAZLEKuCdRq+UGWg4zmfz4ZVs= X-Received: by 2002:a17:906:a14b:: with SMTP id bu11mr36345681ejb.260.1629732549641; Mon, 23 Aug 2021 08:29:09 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Navdeep Parhar Date: Mon, 23 Aug 2021 08:28:58 -0700 Message-ID: Subject: Re: FreeBSD 12.2 traffic not occurs onVXLAN To: alfadev Cc: "freebsd-hackers@FreeBSD.org" , "freebsd-net@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4GtbkZ4DR4z4tdK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Y2nTOvyb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of nparhar@gmail.com designates 2a00:1450:4864:20::630 as permitted sender) smtp.mailfrom=nparhar@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::630:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[protonmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On Sun, Aug 22, 2021 at 8:30 AM alfadev via freebsd-hackers wrote: > > Hi, I successfully configured VXLAN tunnel between amd64 FreeBSD 11.2 to x64 Linux > But in FreeBSD 12.2 with below same configuration not works. > So What is tHe problem with FreeBSD 12.2 is it bug or any other thing? > Any help would be aooreciated.. > > My fully working tested configuration is: > > FreeBSD 11.2 side: > physical interface: igb0 > ifconfig vxlan4095 create vxlanid 4095 vxlanlocal 192.168.99.1 vxlanremote 192.168.99.99 inet 192.168.157.1/24 Can you please provide the ifconfig output for both the vxlan and the physical interface? Have you tried running tcpdump -p on the physical interface to see if there is any VXLAN traffic on the link? Regards, Navdeep > > Linux side: > physical interfaces: eth0,eth1 > > ip link add name vxlan4095 type vxlan id 4095 remote 192.168.99.1 local 192.168.99.99 > ip link add name vbr0 type bridge > ip link set eth1 master vbr0 > ip link set vxlan4095 master vbr0 > ip link set vbr0 up > > there is a client connected on eth1 and have IP : 192.168.157.100 > http https , icmp .. traffic passes through between client and tunnel > eveything works well. From nobody Mon Aug 23 21:49:40 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 38A5C1774FFA for ; Mon, 23 Aug 2021 21:49:49 +0000 (UTC) (envelope-from me@cameronkatri.com) Received: from cameronkatri.com (cameronkatri.com [206.189.178.249]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Gtm9m1zFPz3CyJ for ; Mon, 23 Aug 2021 21:49:48 +0000 (UTC) (envelope-from me@cameronkatri.com) Received: from FreeBSDY540 (c-73-84-80-103.hsd1.fl.comcast.net [73.84.80.103]) by cameronkatri.com (Postfix) with ESMTPSA id ABEDF42022 for ; Mon, 23 Aug 2021 17:49:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cameronkatri.com; s=20201109; t=1629755382; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding:in-reply-to: references; bh=3whXAV95W0sIhHSCwUUPn8CGE5FSL4dvoM5I42F3lrs=; b=T9KKDQqXpHGVQdWpNWhJwP1skIWVJBhM9hWzWhRsBRUlFDnlWG+zpngWmmx/2eYezC7gkx k7YMjWmcT4ZsRyRZZ3kw/ghssyoyeMnwTL3DzItWDwMsnYLY5Z6NzT70k6dwOumMov1+5e 0+UVWSJ4R/oK05eJVktFrHWnclwRjKQ= Date: Mon, 23 Aug 2021 17:49:40 -0400 To: freebsd-hackers@freebsd.org Subject: Submitted FreeBSD Patches Message-ID: <20210823214940.fqnt3myzcp5iay3b@FreeBSDY540> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="73tugx4uadywgmlt" Content-Disposition: inline X-Rspamd-Queue-Id: 4Gtm9m1zFPz3CyJ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cameronkatri.com header.s=20201109 header.b=T9KKDQqX; dmarc=pass (policy=reject) header.from=cameronkatri.com; spf=pass (mx1.freebsd.org: domain of me@cameronkatri.com designates 206.189.178.249 as permitted sender) smtp.mailfrom=me@cameronkatri.com X-Spamd-Result: default: False [-3.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[cameronkatri.com:s=20201109]; FREEFALL_USER(0.00)[me]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(1.00)[1.000]; DKIM_TRACE(0.00)[cameronkatri.com:+]; DMARC_POLICY_ALLOW(-0.50)[cameronkatri.com,reject]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:14061, ipnet:206.189.176.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[73.84.80.103:received] Reply-To: me@cameronkatri.com From: Cameron Katri via freebsd-hackers X-Original-From: Cameron Katri X-ThisMailContainsUnwantedMimeParts: N --73tugx4uadywgmlt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello hackers, I have come outstanding patches on phabricator that I am hoping someone will be able to take a look. I would love any feedback I can get. Here are the differential IDs: D30012 D30341 D30350 D30545 D30547 I hope someone will be able to take a look. Thanks, Cameron Katri --=20 Cameron Katri Email: me@cameronkatri.com PGP Fingerprint: 7D3B36CEA40FCC2181FB6DCDBAFFD97826540F1C --73tugx4uadywgmlt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEfTs2zqQPzCGB+23Nuv/ZeCZUDxwFAmEkF/QACgkQuv/ZeCZU DxwQtQf9EMbViYf5LAtoN5KpF19V7waMglGF8CKsXqSFRjyOgjVU59IbgbNzvXjv D/Y2hPZjnlzxSqIhipzZdyhQCpMiHZZMmBDoknpP+v/zVm/AR4QQm5eSKwzJZFsn HCCXG0a/ibV1im1e3hX3RuKxZ5hZRUH1+gl3rR8gKhrqyyIM0aR+Q7qCHGKN/5pk gUFqRJ23u7jeTrmeDu/EQudfCXBvLvjVdZKBeTp9lOyMYY9FKZk+0P2zlGRJddqc SfsOyPLcxdCwdQYS+PZPqEbwICAIMVtsb4pwveYT+NRbO+CU02Ua/XavkKPdQtuQ sABSuNLkxSz0VGPOZ41QeDW+kXx8XA== =b2kM -----END PGP SIGNATURE----- --73tugx4uadywgmlt-- From nobody Tue Aug 24 08:12:41 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8DF591770D7D for ; Tue, 24 Aug 2021 08:12:52 +0000 (UTC) (envelope-from alfadev@protonmail.com) Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Gv20h2f8mz3m2p for ; Tue, 24 Aug 2021 08:12:52 +0000 (UTC) (envelope-from alfadev@protonmail.com) Date: Tue, 24 Aug 2021 08:12:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1629792764; bh=Uz1c9xsXucNb2EFeipXxaFMCCXMubgEFYlzDGGYOmlk=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=AYt5vC/7IXu2w0kidYpZ9c8i733yzMPu/TVrf+qOmacbj4/BR/Ln6RaECTYxC3yws aTZC0GzDLH6rw4zpUJR8kfcMmwdFNsSjtsWTnlYc9DfUdKSvOS7SPVUarF+RgVYkRE jboaHPUmXHe9UCGgt3aVVgQ2unD9VKbQPbDeyCPc= To: Navdeep Parhar , "freebsd-net@FreeBSD.org" , "freebsd-hackers@FreeBSD.org" Reply-To: alfadev Subject: Re: FreeBSD 12.2 traffic not occurs onVXLAN Message-ID: In-Reply-To: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4Gv20h2f8mz3m2p X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: alfadev@protonmail.com From: alfadev via freebsd-net X-Original-From: alfadev X-ThisMailContainsUnwantedMimeParts: N Thanks for interest FreeBSD ifconfig: igb0: flags=3D8822 metric 0 mtu 1500 =09options=3D4e527bb =09ether e4:3a:6e:44:7b:33 =09inet 192.168.41.102 netmask 0xffffff00 broadcast 192.168.41.255 =09media: Ethernet autoselect (100baseTX ) =09status: active =09nd6 options=3D29 lo0: flags=3D8049 metric 0 mtu 16384 =09options=3D680003 =09inet6 ::1 prefixlen 128 =09inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 =09inet 127.0.0.1 netmask 0xff000000 =09groups: lo =09nd6 options=3D21 vxlan409: flags=3D8843 metric 0 mtu= 1500 =09options=3D80020 =09ether 58:9c:fc:10:d1:3f =09inet 192.168.159.1 netmask 0xffffff00 broadcast 192.168.159.255 =09groups: vxlan =09vxlan vni 409 local 192.168.99.1:4789 remote 192.168.99.99:4789 =09media: Ethernet autoselect (autoselect ) =09status: active =09nd6 options=3D29 wg0: flags=3D80c1 metric 0 mtu 1420 =09options=3D80000 =09inet 192.168.99.1 netmask 0xffffff00 =09groups: wg =09nd6 options=3D109 Linux ifconfig: br-lan Link encap:Ethernet HWaddr E4:3A:6E:41:DC:E9 inet6 addr: fe80::e63a:6eff:fe41:dce9/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1396 errors:0 dropped:0 overruns:0 frame:0 TX packets:475 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:64316 (62.8 KiB) TX bytes:160570 (156.8 KiB) eth0 Link encap:Ethernet HWaddr E4:3A:6E:41:DC:E8 inet addr:192.168.20.232 Bcast:192.168.20.255 Mask:255.255.255.= 0 inet6 addr: fe80::e63a:6eff:fe41:dce8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13884 errors:0 dropped:0 overruns:0 frame:0 TX packets:6588 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2036433 (1.9 MiB) TX bytes:1405173 (1.3 MiB) Memory:f7d00000-f7d1ffff eth1 Link encap:Ethernet HWaddr E4:3A:6E:41:DC:E9 inet addr:169.254.169.169 Bcast:169.254.169.171 Mask:255.255.25= 5.252 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4152 errors:0 dropped:0 overruns:0 frame:0 TX packets:1761 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:258460 (252.4 KiB) TX bytes:587430 (573.6 KiB) Memory:f7c00000-f7c1ffff lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:50 errors:0 dropped:0 overruns:0 frame:0 TX packets:50 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4095 (3.9 KiB) TX bytes:4095 (3.9 KiB) vxlan409 Link encap:Ethernet HWaddr 4E:00:90:B0:A8:DF UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:1857 errors:15 dropped:0 overruns:0 carrier:15 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:216270 (211.2 KiB) wg0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-= 00-00-00 inet addr:192.168.99.99 P-t-P:192.168.99.99 Mask:255.255.255.25= 5 UP POINTOPOINT RUNNING NOARP MTU:1420 Metric:1 RX packets:155 errors:0 dropped:0 overruns:0 frame:0 TX packets:1882 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:5776 (5.6 KiB) TX bytes:373616 (364.8 KiB) Here is tcpdump results: ############################################ root@test13:~ # tcpdump -p port 4789 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on igb0, link-type EN10MB (Ethernet), capture size 262144 bytes root@test13:~ # tcpdump -i wg0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wg0, link-type NULL (BSD loopback), capture size 262144 bytes 10:47:13.277336 IP 192.168.99.99.54996 > 192.168.99.1.vxlan: VXLAN, flags [= I] (0x08), vni 409 ARP, Request who-has 192.168.159.1 tell 192.168.159.100, length 46 10:47:13.633393 IP 192.168.99.99.39365 > 192.168.99.1.vxlan: VXLAN, flags [= I] (0x08), vni 409 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from e4:3a:= 6e:41:dc:e9 (oui Unknown), length 300 10:47:14.301605 IP 192.168.99.99.54996 > 192.168.99.1.vxlan: VXLAN, flags [= I] (0x08), vni 409 ARP, Request who-has 192.168.159.1 tell 192.168.159.100, length 46 root@linux:~# tcpdump -i wg0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes 07:46:39.424139 IP 192.168.99.99.54996 > 192.168.99.1.4789: VXLAN, flags [I= ] (0x08), vni 409 ARP, Request who-has 192.168.159.1 tell 192.168.159.100, length 46 07:46:39.680210 IP 192.168.99.99.39365 > 192.168.99.1.4789: VXLAN, flags [I= ] (0x08), vni 409 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e4:3a:6e:41:dc= :e9 (oui Unknown), length 300 07:46:40.448129 IP 192.168.99.99.54996 > 192.168.99.1.4789: VXLAN, flags [I= ] (0x08), vni 409 ARP, Request who-has 192.168.159.1 tell 192.168.159.100, length 46 07:46:41.472093 IP 192.168.99.99.54996 > 192.168.99.1.4789: VXLAN, flags [I= ] (0x08), vni 409 ################################################## Vxlan traffic only occurs on wg0 it is ok: But when i plug my pc on eth1 (eth1 and vxlan409 in bridge) only ARP request occurs. this problem occurs only freebsd 12.2 and 13.0 STABLE works with Freebsd 11.2 alfa@ubuntu:~# ping 192.168.159.1 root@linux:~# tcpdump -i eth1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 07:52:19.296110 ARP, Request who-has 192.168.159.1 tell 192.168.159.100, le= ngth 46 07:52:20.320148 ARP, Request who-has 192.168.159.1 tell 192.168.159.100, le= ngth 46 07:52:21.344077 ARP, Request who-has 192.168.159.1 tell 192.168.159.100, le= ngth 46 07:52:21.760224 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request fro= m e4:3a:6e:41:dc:e9 (oui Unknown), length 300 Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Monday, August 23rd, 2021 at 6:28 PM, Navdeep Parhar = wrote: > On Sun, Aug 22, 2021 at 8:30 AM alfadev via freebsd-hackers > > freebsd-hackers@freebsd.org wrote: > > > Hi, I successfully configured VXLAN tunnel between amd64 FreeBSD 11.2 t= o x64 Linux > > > > But in FreeBSD 12.2 with below same configuration not works. > > > > So What is tHe problem with FreeBSD 12.2 is it bug or any other thing? > > > > Any help would be aooreciated.. > > > > My fully working tested configuration is: > > > > FreeBSD 11.2 side: > > > > physical interface: igb0 > > > > ifconfig vxlan4095 create vxlanid 4095 vxlanlocal 192.168.99.1 vxlanrem= ote 192.168.99.99 inet 192.168.157.1/24 > > Can you please provide the ifconfig output for both the vxlan and the > > physical interface? Have you tried running tcpdump -p on the physical > > interface to see if there is any VXLAN traffic on the link? > > Regards, > > Navdeep > > > Linux side: > > > > physical interfaces: eth0,eth1 > > > > ip link add name vxlan4095 type vxlan id 4095 remote 192.168.99.1 local= 192.168.99.99 > > > > ip link add name vbr0 type bridge > > > > ip link set eth1 master vbr0 > > > > ip link set vxlan4095 master vbr0 > > > > ip link set vbr0 up > > > > there is a client connected on eth1 and have IP : 192.168.157.100 > > > > http https , icmp .. traffic passes through between client and tunnel > > > > eveything works well. From nobody Tue Aug 24 19:30:44 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F22FC1780F05; Tue, 24 Aug 2021 19:30:57 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GvK345LY2z4Qtt; Tue, 24 Aug 2021 19:30:56 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-ej1-x635.google.com with SMTP id n27so14599000eja.5; Tue, 24 Aug 2021 12:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j9KW+9g6P1pfnnM8GM3q5nMj5aGviBvPG+rJ4hHDu64=; b=DeB+Kewsr/lgRhffQL7x88KXbzgzl+uteXCZ1RnsVUhJfUYfrekx23pO8AZ+YZpxpB OiOrenMCcv37JjxJBKO6kcyWA3ym4NAaFygCYCVsO8OPbiPmcDRWjZDG9DnF2mWHz117 p+nYQaJYZIwuLLLNBBI+RMbIy2u79Vj/IVz/UL7zU+fy7/I1aQJRlMVTZ6DdAkTs93Ti BS+uqqTVncz+PKT1ZVKcYc/ItUZUn3DxORkAU0EUV1bjcv3raueGETvwJezKg1GuinGs nSe1tq2F3+klqbzZkts1ir3/kXRp42BjSITs/n/FPFamQZfjadh8wY5t352CZ3ZK7kig eEwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j9KW+9g6P1pfnnM8GM3q5nMj5aGviBvPG+rJ4hHDu64=; b=mNxROKA616rPNBAs5Thx0lBCfrGhUVkmvetbF51hf0xHBlpUP3j1y7jwU6f8OPbYRe D5JY0ao3X5KD92BBjZrdv1mERhX3pP369YAM1gqUhwjh7SWamckS9yx9F3uRq4DcASD9 Owj8Ho+mVmoBtR10KCUbVIeBgpKWdJx3GU9w0Qe8or979mOW4LNWjiYEtFeX1xYKFYhX 6MspmOEOiVh9mQXY3s2qIQDKAQniFCKj038QNPtAKh5hgtKkxpS1cgM0Mfnt/Eq7/aZE IbpaYCf9lPUldxcbxa5Ff3Px4SC6sCy3xHVeuulu5PxWiX0+ArLOB3WJsNYJ9qAg3Gen WsMQ== X-Gm-Message-State: AOAM533jNfa3Y8MFBDOSHj6DuioIYDvnfXx5DNeU/agg5+S5yhA+PzhK StlzPm9+bXwIH1H2pV55I5UtbUiWBE2FgSvPJ1g= X-Google-Smtp-Source: ABdhPJwEZsYXEOOFpEVjT5hwuAw8mOwUcUVXYvoZQBjsc7i//Yguw+Bw91OJ7AdKBT2p56+24K82CVMp4shK2CWZvZE= X-Received: by 2002:a17:906:95c9:: with SMTP id n9mr43100778ejy.178.1629833455735; Tue, 24 Aug 2021 12:30:55 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Navdeep Parhar Date: Tue, 24 Aug 2021 12:30:44 -0700 Message-ID: Subject: Re: FreeBSD 12.2 traffic not occurs onVXLAN To: alfadev Cc: "freebsd-net@FreeBSD.org" , "freebsd-hackers@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4GvK345LY2z4Qtt X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=DeB+Kews; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of nparhar@gmail.com designates 2a00:1450:4864:20::635 as permitted sender) smtp.mailfrom=nparhar@gmail.com X-Spamd-Result: default: False [-3.43 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::635:from]; NEURAL_HAM_SHORT(-0.43)[-0.430]; FREEMAIL_TO(0.00)[protonmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On Tue, Aug 24, 2021 at 1:12 AM alfadev wrote: > > Thanks for interest > FreeBSD ifconfig: > > igb0: flags=8822 metric 0 mtu 1500 ... > wg0: flags=80c1 metric 0 mtu 1420 igb0 should be UP and RUNNING before it will pass traffic. You can see that the wireguard interface is fully operational (has both those flags) and you are able to use it for VXLAN traffic. Maybe the difference between the FreeBSD versions is that igb0 is UP after all your configuration commands on 11.2 only? Regards, Navdeep From nobody Thu Aug 26 01:09:29 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0210F178944A for ; Thu, 26 Aug 2021 01:09:40 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4Gw4WR1mDLz4pZR for ; Thu, 26 Aug 2021 01:09:38 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 17Q19T3f092892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Aug 2021 02:09:29 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 17Q19TR1092883; Thu, 26 Aug 2021 02:09:29 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202108260109.17Q19TR1092883@donotpassgo.dyslexicfish.net> Date: Thu, 26 Aug 2021 02:09:29 +0100 Organization: Dyslexic Fish To: freebsd-hackers@FreeBSD.org, antranigv@freebsd.am Subject: Re: Need advice: Better Jail integration into ps/top, setpwfile gone forever? References: <1B45F065-DC9D-40C9-958F-7D4D64DE8993@freebsd.am> In-Reply-To: <1B45F065-DC9D-40C9-958F-7D4D64DE8993@freebsd.am> User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Thu, 26 Aug 2021 02:09:30 +0100 (BST) X-Rspamd-Queue-Id: 4Gw4WR1mDLz4pZR X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-2.06 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; FREEFALL_USER(0.00)[jamie]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.37)[-0.366]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N I have no specific answer to your questions, but just a few thoughts: As a policy, I allocate a uid/gid range to the jails that are unused on the host. I only do it with user accounts, servers/daemons are left as they are. (though ideally they would be changed too) To improve on this, I think a per-jail configurable "uid" and "gid" offset would seem a good idea, so for instance, if you set jail_uid_increment = 10000 then anything with uid "0" in the jail would actually be running under uid 10,000 but the jail would translate the uid/gid on the fly inside the jail. That would help when the jails are administered by other people who you can't guarantee will follow your policy. Having a jail uid/gid being used by a host user/group can cause other problems: - Any user on the host must be trusted, because they have access to processes running under the jail that use their uid. - Even if you patch ps and top, the issue you cite could come back to bite in the - future in other ways (How can a non jail-aware program grok this response if a - username exists in the host and the jail, but with different uid's? (the same - principle applies to groups too)) Finally, if you do proceed with this, do you think it would be a good idea to prefix the result with the jail number? I.E. In your case, something like "1:antranigv" Just a few thoughts, it will be interesting to see how you progress, as this was something that bugged me when I was managing jails. Cheers, Jamie From nobody Thu Aug 26 01:43:19 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 70D87179866F for ; Thu, 26 Aug 2021 01:43:38 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Gw5Gd2wtWz3Fn9 for ; Thu, 26 Aug 2021 01:43:37 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f50.google.com with SMTP id c19-20020a9d6153000000b0051829acbfc7so1418160otk.9 for ; Wed, 25 Aug 2021 18:43:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mZiZmBPRNnV1kbll6jRV9aGbT8HEApo+Npt8JPAQ+pQ=; b=ixZ3wYs4lKybH5KvhBbl246vN9pij6UAZmtbQv9Th7NFmodbgsjtHQwFRT/Ta64124 0LopDRD2ZWklEe1jPbAoE4NDzVXejV2hO4jaXVFDvDK2j47/YD/JK2GbApay0A14OEWh WFXPJEpUQCHb3V87oJTi8eRSX09i/Fi11GvXE30f4P677f4BoSiViTzQEhY4lm8wVACn zLKIhZfuvJY/D00p3tShHTf1TWyffF7okL8Ignh3rOAEA+6F5HXCgulm/DVVhzR8DZqP a7HmDL4KMunFx+8LTug08tBpR8wpQ1LBQ3kyoSLoSjCC48KYVbDvY+rxrShP3Oo443OK BPzQ== X-Gm-Message-State: AOAM532bqLCkukvQ8yp6r7uXaRW/mRZyDzptW1NeNF/mZy1E9ebd+rcN tlhOIHzE6I1nI41n16AyFUo/jeFwgd8Jyac4vW4XtYl2 X-Google-Smtp-Source: ABdhPJw9edqB9Zbasnth1kusBFPnXu1LUs2ye9ce5x4gGNa4+1Tdc6qB0+KEF9eeaTSozaGr7EXZ42o46wzSWD9Bc8Y= X-Received: by 2002:a9d:d04:: with SMTP id 4mr1124649oti.251.1629942210904; Wed, 25 Aug 2021 18:43:30 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <1B45F065-DC9D-40C9-958F-7D4D64DE8993@freebsd.am> In-Reply-To: <1B45F065-DC9D-40C9-958F-7D4D64DE8993@freebsd.am> From: Alan Somers Date: Wed, 25 Aug 2021 19:43:19 -0600 Message-ID: Subject: Re: Need advice: Better Jail integration into ps/top, setpwfile gone forever? To: antranigv Cc: "freebsd-hackers@FreeBSD.org" Content-Type: multipart/alternative; boundary="0000000000007c465e05ca6c7e06" X-Rspamd-Queue-Id: 4Gw5Gd2wtWz3Fn9 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.210.50 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-0.12 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.50:from]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.88)[0.876]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.50:from]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y --0000000000007c465e05ca6c7e06 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 23, 2021 at 4:03 AM antranigv wrote: > Greetings all, > > I am trying to have better integration of top(1) and ps(1) with FreeBSD > Jails. > > The main problem that I am trying to solve is displaying the correct UID > username. Here's an example. > > I have a host (srv0), it is running a Jail named "fsoc", The Jail "fsoc" > has a user named "romero" with the UID 1001. > > If I run `ps auxd` in the Jail, I get the following, > > romero@fsoc:~ $ ps auxd > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > root 4377 0.0 0.0 11376 956 - SsJ 14:15 0:00.38 > /usr/sbin/syslogd -ss > root 5758 0.0 0.1 13128 1352 1 IJ 18:24 0:00.02 /bin/tcsh -i > root 5763 0.0 0.0 12048 960 1 IJ 18:24 0:00.01 - su - romero > romero 5764 0.0 0.1 12120 2268 1 SJ 18:24 0:00.02 `-- -su (sh) > romero 9625 0.0 0.1 11684 2576 1 R+J 09:41 0:00.01 `-- ps auxd > > Good! > > However, if I try to run it on the host, here's what I get, > > root@srv0:~ # ps auxd -J fsoc > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > root 4377 0.0 0.0 11376 956 - SsJ 14:15 0:00.38 /usr/sbin/syslogd > -ss > root 5758 0.0 0.1 13128 1352 1 IJ 18:24 0:00.02 /bin/tcsh -i > root 5763 0.0 0.0 12048 960 1 IJ 18:24 0:00.01 - su - romero > 1001 5764 0.0 0.1 12124 2436 1 I+J 18:24 0:00.02 `-- -su (sh) > > As you can see, in the User field it says 1001, because the host does not > have a user with that UID. > > This seems fine, but it becomes an issue when you have multiple Jail and a > large host running. > > Here's an example if the host had a user with UID 1001, > > root@pingvinashen:~ # ps auxd -J oragir > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > root 949 0.0 0.0 11344 2584 - IsJ Mon19 0:01.13 > /usr/sbin/cron -s > root 1962 0.0 0.0 11428 2796 - SsJ Mon19 0:01.83 > /usr/sbin/syslogd -ss > antranigv 95342 0.0 0.0 11004 2424 - IsJ Mon19 0:00.48 daemon: > /usr/home/oragir/writefreely/writefreely[9992] (daemon) > antranigv 9992 0.0 0.4 767244 58336 - IJ Mon19 2:58.87 - > /usr/home/oragir/writefreely/writefreely > > Now, you would think that this is good, however, if you run this in the > jail, > > root@oragir:~ # ps auxd > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > root 949 0.0 0.0 11344 2584 - SsJ Mon15 0:01.13 > /usr/sbin/cron -s > root 1962 0.0 0.0 11428 2796 - SsJ Mon15 0:01.83 > /usr/sbin/syslogd -ss > oragir 95342 0.0 0.0 11004 2424 - IsJ Mon15 0:00.48 daemon: > /usr/home/oragir/writefreely/writefreely[9992] (daemon) > oragir 9992 0.0 0.4 767244 58336 - IJ Mon15 2:58.88 - > /usr/home/oragir/writefreely/writefreely > root 88228 0.0 0.0 13336 4004 8 SJ 09:45 0:00.01 /bin/csh -i > root 99502 0.0 0.0 11824 3140 8 R+J 09:45 0:00.00 - ps auxd > > As you can see, the UID 1001 was not `antranigv`, instead it was `oragir`. > > This has been an issue for me, so I tried writing some code to implement > the following. > > If the process is in a Jail, then change the passwd db from /etc to > /path/of/the/jail/etc. > > I thought it would be an easy thing to do, but not so much. > > Here's what I've tried. > > 1) Call jail_attach and run ps inside the Jail. Oh yeah, it's a jail! > after attaching to it there is no way to deattach :-) silly me! > > 2) Change the passwd file for getpwuid/getpwnam. I wanted to use > setpwfile(3) but turns out that \ > COMPATIBILITY > The historic function setpwfile(3), which allowed the specification of > alternate password databases, has been deprecated and is no longer > available. > > Okay, So I look into how other tools like pwd_mkdb is written and I see > that everything is defined (pun intended) the following way, > > in /usr/include/pwd.h > > #define _PATH_PWD "/etc" > #define _PATH_PASSWD "/etc/passwd" > #define _PASSWD "passwd" > #define _PATH_MASTERPASSWD "/etc/master.passwd" > #define _MASTERPASSWD "master.passwd" > > #define _PATH_MP_DB "/etc/pwd.db" > #define _MP_DB "pwd.db" > #define _PATH_SMP_DB "/etc/spwd.db" > #define _SMP_DB "spwd.db" > > #define _PATH_PWD_MKDB "/usr/sbin/pwd_mkdb" > > and pwd_mkdb does the following > > ... > strcpy(prefix, _PATH_PWD); > ... > case 'd': > dflag++; > strlcpy(prefix, optarg, sizeof(prefix)); > break; > ... > > Tuns out it parses the DB file, but I don't want to do that in ps/top! :-) > > 3) Just for fun, I played with chroot. I tried the following code. > # cat getpw.c > > #define MAXHOSTNAMELEN 255 > #define MAXPATHLEN 255 > #include > //#include > #include > #include > #include > #include > #include > #include > > int main(){ > // Just get root! > struct passwd *pwd; > printf("just root: %s\n", (getpwuid(0))->pw_name); > > // let's try with undef/define > #undef _PATH_PWD > #undef _PATH_PASSWD > #undef _PASSWD > #undef _PATH_MASTERPASSWD > #undef _MASTERPASSWD > > #undef _PATH_MP_DB > #undef _MP_DB > #undef _PATH_SMP_DB > #undef _SMP_DB > > #define _PATH_PWD "/zdata/jails/fsoc/etc" > #define _PATH_PASSWD "/zdata/jails/fsoc/etc/passwd" > #define _PASSWD "passwd" > #define _PATH_MASTERPASSWD "/zdata/jails/fsoc/etc/master.passwd" > #define _MASTERPASSWD "master.passwd" > > #define _PATH_MP_DB "/zdata/jails/fsoc/etc/pwd.db" > #define _MP_DB "pwd.db" > #define _PATH_SMP_DB "/zdata/jails/fsoc/etc/spwd.db" > #define _SMP_DB "spwd.db" > pwd = getpwuid(1001); > if (pwd == NULL) { > printf("using undef/define: no user found\n"); > } else { > printf("using undef/define: %s\n", pwd->pw_name); > } > > // let's try with chroot! > chroot("/zdata/jails/fsoc"); > pwd = getpwuid(1001); > if (pwd == NULL) { > printf("after chroot: no user found\n"); > } else { > printf("after chroot: %s\n", pwd->pw_name); > } > > // escape back the chroot ;-) > chroot("../../../../"); > pwd = getpwuid(1001); > if (pwd == NULL) { > printf("after unchroot: no user found\n"); > } else { > printf("after chroot: %s\n", pwd->pw_name); > } > > return 42; > } > > And I get the following: > > # ./getpw > just root: root > using undef/define: no user found > after chroot: romero > after unchroot: no user found > > So, any advice? should I do chroot in ps? (no I don't think that's a good > idea), should I add a new call that implements setpwfile(3)? But I really > want to know why it was removed, I'm sure there's a story there. Or is > there a better way? > > Kind regards, have a nice day! > > -- > antranigv > https://antranigv.am/ > Oof, that's a hard problem. But in fact, it's worse than you think. /etc/passwd isn't the only place that user information is stored. It could be in NIS, or LDAP, or Heimdal, or who knows where. The only reliable way to look up a user is to actually do it from within the jail. You could create a socketpair, then fork a child process and attach that to the jail, and use it to lookup jailed UIDs. It's complicated, but I can't imagine anything simpler that would work. -Alan --0000000000007c465e05ca6c7e06-- From nobody Fri Aug 27 09:34:48 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4F3DF178EE9F for ; Fri, 27 Aug 2021 09:35:02 +0000 (UTC) (envelope-from antranigv@freebsd.am) Received: from evncert.am (evncert.am [212.42.214.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Gwvh434jBz3MY7; Fri, 27 Aug 2021 09:34:59 +0000 (UTC) (envelope-from antranigv@freebsd.am) Received: from evncert.am (localhost [127.0.0.1]) by evncert.am (OpenSMTPD) with ESMTP id 39982816; Fri, 27 Aug 2021 13:45:55 +0400 (+04) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=freebsd.am; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector0; bh=IhMibG94qpeUkGFlLqQDjji6uSM=; b=bbJ2b4cpy1oqo1C7jG XpBRrvgkqqVw330pYktdS2V5DQ0YMFHfqpz86g6aNz6A9eEzMI6Ufc7VaxeaMNwl XSa0hwkVYRjGV82e65xh3V+CB4p3LQTb2+MkTkZ9RufzCk+KJ4vjL0d0bJyQUJTs BqdNLefa19v2JY7YW2T0J+v/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=freebsd.am; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector0; b=Exp24oGmc5ZY3Pkfl8jRTglfDFZbMW/j3PT/AzDtB6/FDNE8HdJ bY2gWNksfgNST/l2XNTIAsfali0A/1OgjjUDRYvxH7jLgVp3NBwrxoeyzthS0n2r 5cL0eTMKxYHmC7/ukcInh9Suke8qgSkrTLbIa1HkMV2vrUmBSoZPMZR4= Received: by post.evncert.am (OpenSMTPD) with ESMTPSA id e55cd752 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Fri, 27 Aug 2021 13:45:55 +0400 (+04) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Need advice: Better Jail integration into ps/top, setpwfile gone forever? From: antranigv In-Reply-To: Date: Fri, 27 Aug 2021 13:34:48 +0400 Cc: "freebsd-hackers@FreeBSD.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5DB070E0-2602-4C15-B950-920B56506E15@freebsd.am> References: <1B45F065-DC9D-40C9-958F-7D4D64DE8993@freebsd.am> To: Alan Somers , Jamie Landeg-Jones X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Gwvh434jBz3MY7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=freebsd.am header.s=selector0 header.b=bbJ2b4cp; dmarc=pass (policy=none) header.from=freebsd.am; spf=pass (mx1.freebsd.org: domain of antranigv@freebsd.am designates 212.42.214.164 as permitted sender) smtp.mailfrom=antranigv@freebsd.am X-Spamd-Result: default: False [-2.30 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[freebsd.am:~]; DMARC_POLICY_ALLOW(-0.50)[freebsd.am,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_PERMFAIL(0.00)[freebsd.am:s=selector0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:49800, ipnet:212.42.192.0/19, country:AM]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N Dear Jamie and Alan, Thank you both for your inputs. Jamie, I totally understand your point, for an issue like this to be = fixed, we=20 need to patch some subsystem. I'm not sure I have enough knowledge to do = that,=20 but what you point is called UID Virtualization. If I am not mistaken = illumos=20 systems do that for their Zones. I have to get into it, hopefully = something=20 similar can be done with FreeBSD. So, 1) Yes, patching only ps/top will not solve the issue, what about htop?=20= sockstat? procstat? etc. 2) The ideal way is to make a major change. Look into what other systems = are=20 doing and try to implement it here. Alan, I got a PoC working! #include #include #include #include #include #include #include #include #include int main(int argc, char *argv[]){ struct passwd *pwd; int sp[2], uid; pid_t pid; if (argc < 2 ) { printf("usage: psjail UID\n"); exit(1); } uid =3D atoi(argv[1]); printf("Got UID: %d\n", uid); socketpair(PF_LOCAL, SOCK_STREAM, 0, sp); pid =3D fork(); if (pid =3D=3D 0){ printf("In the child process\n"); printf("Going into Jail\n"); jail_attach(35); pwd =3D getpwuid(uid); if (pwd =3D=3D NULL) { printf("In the Jail: no user found\n"); write(sp[1], "", sizeof(pwd)); } else { printf("In the Jail: %s\n", pwd->pw_name); write(sp[1], pwd->pw_name, = sizeof(pwd->pw_name)); printf("Message sent\n"); } _Exit(0); } else { char buf[sizeof(pwd->pw_name)]; printf("I'm the parent\n"); int n =3D read(sp[0], buf, sizeof(pwd->pw_name)); printf("got %d bytes\n", n); printf("parent got : '%s'\n", buf); pwd =3D getpwuid(uid); if (pwd =3D=3D NULL) { printf("In the parent: no user found\n"); } else { printf("In the parent: %s\n", pwd->pw_name); } } printf("Done executing\n"); return 42; } Here's a sample output, root@srv0:~/src # ./spjail 1001 Got UID: 1001 I'm the parent In the child process Going into Jail In the Jail: romero Message sent got 8 bytes parent got : 'romero' In the parent: no user found Done executing root@srv0:~/src # ./spjail 1000 Got UID: 1000 I'm the parent In the child process Going into Jail In the Jail: no user found got 8 bytes parent got : '' In the parent: no user found Done executing Now, as Jamie said, this is not a good idea, it's basically a "Hack." I = will=20 try to find a proper way to virtualize the UID table, write a PoC for = that and=20 see what the community thinks about that. I like Jamie's approach, but I would not want it to be manual. We need = some=20 automated way. Sure, I can integrate that into my Jail Orchestrator, but = some=20 people want to use jail(8) with jail.conf, and it should be simple for = them as=20 well. Thank you all. Any more input will be appreciated. Kind regards, -- antranigv https://antranigv.am/ > On 26 Aug 2021, at 5:43 AM, Alan Somers wrote: >=20 > On Mon, Aug 23, 2021 at 4:03 AM antranigv = wrote: >=20 >> Greetings all, >>=20 >> I am trying to have better integration of top(1) and ps(1) with = FreeBSD >> Jails. >>=20 >> The main problem that I am trying to solve is displaying the correct = UID >> username. Here's an example. >>=20 >> I have a host (srv0), it is running a Jail named "fsoc", The Jail = "fsoc" >> has a user named "romero" with the UID 1001. >>=20 >> If I run `ps auxd` in the Jail, I get the following, >>=20 >> romero@fsoc:~ $ ps auxd >> USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND >> root 4377 0.0 0.0 11376 956 - SsJ 14:15 0:00.38 >> /usr/sbin/syslogd -ss >> root 5758 0.0 0.1 13128 1352 1 IJ 18:24 0:00.02 /bin/tcsh = -i >> root 5763 0.0 0.0 12048 960 1 IJ 18:24 0:00.01 - su - = romero >> romero 5764 0.0 0.1 12120 2268 1 SJ 18:24 0:00.02 `-- -su = (sh) >> romero 9625 0.0 0.1 11684 2576 1 R+J 09:41 0:00.01 `-- ps = auxd >>=20 >> Good! >>=20 >> However, if I try to run it on the host, here's what I get, >>=20 >> root@srv0:~ # ps auxd -J fsoc >> USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND >> root 4377 0.0 0.0 11376 956 - SsJ 14:15 0:00.38 = /usr/sbin/syslogd >> -ss >> root 5758 0.0 0.1 13128 1352 1 IJ 18:24 0:00.02 /bin/tcsh -i >> root 5763 0.0 0.0 12048 960 1 IJ 18:24 0:00.01 - su - romero >> 1001 5764 0.0 0.1 12124 2436 1 I+J 18:24 0:00.02 `-- -su (sh) >>=20 >> As you can see, in the User field it says 1001, because the host does = not >> have a user with that UID. >>=20 >> This seems fine, but it becomes an issue when you have multiple Jail = and a >> large host running. >>=20 >> Here's an example if the host had a user with UID 1001, >>=20 >> root@pingvinashen:~ # ps auxd -J oragir >> USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME = COMMAND >> root 949 0.0 0.0 11344 2584 - IsJ Mon19 0:01.13 >> /usr/sbin/cron -s >> root 1962 0.0 0.0 11428 2796 - SsJ Mon19 0:01.83 >> /usr/sbin/syslogd -ss >> antranigv 95342 0.0 0.0 11004 2424 - IsJ Mon19 0:00.48 = daemon: >> /usr/home/oragir/writefreely/writefreely[9992] (daemon) >> antranigv 9992 0.0 0.4 767244 58336 - IJ Mon19 2:58.87 - >> /usr/home/oragir/writefreely/writefreely >>=20 >> Now, you would think that this is good, however, if you run this in = the >> jail, >>=20 >> root@oragir:~ # ps auxd >> USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND >> root 949 0.0 0.0 11344 2584 - SsJ Mon15 0:01.13 >> /usr/sbin/cron -s >> root 1962 0.0 0.0 11428 2796 - SsJ Mon15 0:01.83 >> /usr/sbin/syslogd -ss >> oragir 95342 0.0 0.0 11004 2424 - IsJ Mon15 0:00.48 daemon: >> /usr/home/oragir/writefreely/writefreely[9992] (daemon) >> oragir 9992 0.0 0.4 767244 58336 - IJ Mon15 2:58.88 - >> /usr/home/oragir/writefreely/writefreely >> root 88228 0.0 0.0 13336 4004 8 SJ 09:45 0:00.01 = /bin/csh -i >> root 99502 0.0 0.0 11824 3140 8 R+J 09:45 0:00.00 - ps = auxd >>=20 >> As you can see, the UID 1001 was not `antranigv`, instead it was = `oragir`. >>=20 >> This has been an issue for me, so I tried writing some code to = implement >> the following. >>=20 >> If the process is in a Jail, then change the passwd db from /etc to >> /path/of/the/jail/etc. >>=20 >> I thought it would be an easy thing to do, but not so much. >>=20 >> Here's what I've tried. >>=20 >> 1) Call jail_attach and run ps inside the Jail. Oh yeah, it's a jail! >> after attaching to it there is no way to deattach :-) silly me! >>=20 >> 2) Change the passwd file for getpwuid/getpwnam. I wanted to use >> setpwfile(3) but turns out that \ >> COMPATIBILITY >> The historic function setpwfile(3), which allowed the = specification of >> alternate password databases, has been deprecated and is no = longer >> available. >>=20 >> Okay, So I look into how other tools like pwd_mkdb is written and I = see >> that everything is defined (pun intended) the following way, >>=20 >> in /usr/include/pwd.h >>=20 >> #define _PATH_PWD "/etc" >> #define _PATH_PASSWD "/etc/passwd" >> #define _PASSWD "passwd" >> #define _PATH_MASTERPASSWD "/etc/master.passwd" >> #define _MASTERPASSWD "master.passwd" >>=20 >> #define _PATH_MP_DB "/etc/pwd.db" >> #define _MP_DB "pwd.db" >> #define _PATH_SMP_DB "/etc/spwd.db" >> #define _SMP_DB "spwd.db" >>=20 >> #define _PATH_PWD_MKDB "/usr/sbin/pwd_mkdb" >>=20 >> and pwd_mkdb does the following >>=20 >> ... >> strcpy(prefix, _PATH_PWD); >> ... >> case 'd': >> dflag++; >> strlcpy(prefix, optarg, sizeof(prefix)); >> break; >> ... >>=20 >> Tuns out it parses the DB file, but I don't want to do that in = ps/top! :-) >>=20 >> 3) Just for fun, I played with chroot. I tried the following code. >> # cat getpw.c >>=20 >> #define MAXHOSTNAMELEN 255 >> #define MAXPATHLEN 255 >> #include >> //#include >> #include >> #include >> #include >> #include >> #include >> #include >>=20 >> int main(){ >> // Just get root! >> struct passwd *pwd; >> printf("just root: %s\n", (getpwuid(0))->pw_name); >>=20 >> // let's try with undef/define >> #undef _PATH_PWD >> #undef _PATH_PASSWD >> #undef _PASSWD >> #undef _PATH_MASTERPASSWD >> #undef _MASTERPASSWD >>=20 >> #undef _PATH_MP_DB >> #undef _MP_DB >> #undef _PATH_SMP_DB >> #undef _SMP_DB >>=20 >> #define _PATH_PWD "/zdata/jails/fsoc/etc" >> #define _PATH_PASSWD "/zdata/jails/fsoc/etc/passwd" >> #define _PASSWD "passwd" >> #define _PATH_MASTERPASSWD "/zdata/jails/fsoc/etc/master.passwd" >> #define _MASTERPASSWD "master.passwd" >>=20 >> #define _PATH_MP_DB "/zdata/jails/fsoc/etc/pwd.db" >> #define _MP_DB "pwd.db" >> #define _PATH_SMP_DB "/zdata/jails/fsoc/etc/spwd.db" >> #define _SMP_DB "spwd.db" >> pwd =3D getpwuid(1001); >> if (pwd =3D=3D NULL) { >> printf("using undef/define: no user found\n"); >> } else { >> printf("using undef/define: %s\n", pwd->pw_name); >> } >>=20 >> // let's try with chroot! >> chroot("/zdata/jails/fsoc"); >> pwd =3D getpwuid(1001); >> if (pwd =3D=3D NULL) { >> printf("after chroot: no user found\n"); >> } else { >> printf("after chroot: %s\n", pwd->pw_name); >> } >>=20 >> // escape back the chroot ;-) >> chroot("../../../../"); >> pwd =3D getpwuid(1001); >> if (pwd =3D=3D NULL) { >> printf("after unchroot: no user found\n"); >> } else { >> printf("after chroot: %s\n", pwd->pw_name); >> } >>=20 >> return 42; >> } >>=20 >> And I get the following: >>=20 >> # ./getpw >> just root: root >> using undef/define: no user found >> after chroot: romero >> after unchroot: no user found >>=20 >> So, any advice? should I do chroot in ps? (no I don't think that's a = good >> idea), should I add a new call that implements setpwfile(3)? But I = really >> want to know why it was removed, I'm sure there's a story there. Or = is >> there a better way? >>=20 >> Kind regards, have a nice day! >>=20 >> -- >> antranigv >> https://antranigv.am/ >>=20 >=20 > Oof, that's a hard problem. But in fact, it's worse than you think. > /etc/passwd isn't the only place that user information is stored. It > could be in NIS, or LDAP, or Heimdal, or who knows where. The only > reliable way to look up a user is to actually do it from within the = jail. > You could create a socketpair, then fork a child process and attach = that to > the jail, and use it to lookup jailed UIDs. It's complicated, but I = can't > imagine anything simpler that would work. > -Alan