git: 140119a60d96 - main - ifconfig.8: add missing "be"
The branch main has been updated by bjk: URL: https://cgit.FreeBSD.org/src/commit/?id=140119a60d967a05aafe80550aae28407db5ad79 commit 140119a60d967a05aafe80550aae28407db5ad79 Author: PauAmma AuthorDate: 2024-03-15 20:59:35 + Commit: Benjamin Kaduk CommitDate: 2024-03-15 21:16:53 + ifconfig.8: add missing "be" Reviewed by:allanjude, bjk MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D44022 --- sbin/ifconfig/ifconfig.8 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sbin/ifconfig/ifconfig.8 b/sbin/ifconfig/ifconfig.8 index 1fe1b1876f81..b88772e0e5e9 100644 --- a/sbin/ifconfig/ifconfig.8 +++ b/sbin/ifconfig/ifconfig.8 @@ -1068,7 +1068,7 @@ Legacy .Cm wds devices have a fixed peer relationship and do not, for example, roam if their peer stops communicating. -For completeness a Dynamic WDS (DWDS) interface may marked as +For completeness a Dynamic WDS (DWDS) interface may be marked as .Fl wdslegacy . .It Cm bssid Request a unique local mac address for the cloned device.
Re: git: 70e64ba44941 - main - release.sh: Update GITROOT URL
On Thu, Dec 31, 2020 at 10:25 AM John Baldwin wrote: > On 12/30/20 1:18 PM, Rodney W. Grimes wrote: > > Take for example all the files in /etc, these files can easily > > at present often be tracked back to exactly what release installed > > them cause the $FreeBSD$ points you at it. These files are often > > modified by local administrators, and with out knowing what version > > they started out it is a crap shoot to ever figure it out unless > > the local mods are minor and you get lucky. > > > > Contractors are some times hired to go in and upgrade or clean up > > after someone else did work, and not having this information and > > telling them to go dig in git to try and figure out the state of > > there system is pretty much a non-started, well at least it is for > > me. > > Have you seen 'etcupdate diff'? With pkgbase I'm hopeful we will > have a similar 'pkg confdiff' type functionality (for ports as well as > base) where packages keep stock config files around while installed > that existing ones can be compared against (and that can be used for > 3 way merges during upgrades similar to what etcupdate does). > > (etcupdate diff is explicitly designed due to experience in sysadmin > mode and etcupdate in general is designed with the goal of rolling > out new snapshots to fleets of machines requiring minimal user > intervention) > > More generally I would make the analogy to keeping metadata about a given data object in-band with the data vs. separately tracked. Generally, the in-band data cannot be authenticated very well and can be malleable, letting the metadata get out of sync with the data both when the data is modified and when the metadata is modified. It's generally easier to build robust and secure systems when the metadata is tracked separately from the data itself. This is the general model that etcupdate fits into (keeping a pristine copy of the file along with versioning/identification information), as well as puppet and similar fleet-management tools. In the latter case the expected configuration and versioning is tracked and authenticated centrally, and any local modifications or deviations from the expected state can be flagged for follow-up. -Ben ___ dev-commits-src-main@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/dev-commits-src-main To unsubscribe, send any mail to "dev-commits-src-main-unsubscr...@freebsd.org"
git: 43d0803c4545 - main - Soften caveat about fractional seconds for sleep(1)
The branch main has been updated by bjk (doc committer): URL: https://cgit.FreeBSD.org/src/commit/?id=43d0803c4545861e8f2411aec0987968b2e4a299 commit 43d0803c4545861e8f2411aec0987968b2e4a299 Author: Benjamin Kaduk AuthorDate: 2021-01-01 03:17:40 + Commit: Benjamin Kaduk CommitDate: 2021-01-01 03:18:20 + Soften caveat about fractional seconds for sleep(1) Support for fractional seconds has become much more widespread since this text was originally written. Reported by:Mark Eichin Reviewed by:gbe, jilles Differential Revision: https://reviews.freebsd.org/D26208 --- bin/sleep/sleep.1 | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bin/sleep/sleep.1 b/bin/sleep/sleep.1 index 937c78abdb15..924bc732a0d0 100644 --- a/bin/sleep/sleep.1 +++ b/bin/sleep/sleep.1 @@ -32,7 +32,7 @@ .\"@(#)sleep.1 8.3 (Berkeley) 4/18/94 .\" $FreeBSD$ .\" -.Dd April 18, 1994 +.Dd December 31, 2020 .Dt SLEEP 1 .Os .Sh NAME @@ -65,8 +65,8 @@ The command allows and honors a non-integer number of seconds to sleep in any form acceptable by .Xr strtod 3 . -This is a non-portable extension, and its use will nearly guarantee that -a shell script will not execute properly on another system. +This is a non-portable extension, but is also implemented in GNU sh-utils +since version 2.0a (released in 2002). .Sh EXIT STATUS .Ex -std .Sh EXAMPLES ___ dev-commits-src-main@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/dev-commits-src-main To unsubscribe, send any mail to "dev-commits-src-main-unsubscr...@freebsd.org"
Re: git: 2b68eb8e1dbb - main - vfs: remove thread argument from VOP_STAT
On Mon, Oct 11, 2021 at 6:22 AM Mateusz Guzik wrote: > The branch main has been updated by mjg: > > URL: > https://cgit.FreeBSD.org/src/commit/?id=2b68eb8e1dbbdaf6a0df1c83b26f5403ca52d4c3 > > commit 2b68eb8e1dbbdaf6a0df1c83b26f5403ca52d4c3 > Author: Mateusz Guzik > AuthorDate: 2021-10-01 22:25:39 + > Commit: Mateusz Guzik > CommitDate: 2021-10-11 13:22:32 + > > vfs: remove thread argument from VOP_STAT > > > Any plans for __FreeBSD_version bump? -Ben
Re: git: 225639e7db68 - main - vt: Disable bell by default
On Fri, Oct 22, 2021 at 10:47 AM Emmanuel Vadot wrote: > On Fri, 22 Oct 2021 10:04:15 -0700 (PDT) > "Rodney W. Grimes" wrote: > > > We need to STOP these "I dont like the 20 year old defaults, > > so I am going to change them to what I like and use" It is NOT > > forward progress on making a better system, it is tilting at > > defaults, very long established defaults, that should probably > > just be left alone. > > It's not "I don't like", it's "We don't like". If we can't change > FreeBSD default to what most of our users want I don't know why we're > still working on this OS. > **We** can change the defaults. But to know that we, as a community, have consensus to make the change, we need to have a conversation. Having that conversation before making the change seems like a much better [*] approach than presenting the change as a fait accompli and waiting for dissent. In other words, I am okay with changing the default (I personally do not feel a need for it), but am unhappy that there was no conversation about it other than a phabricator review that was apparently only open for about a day. -Ben * I have some other, more precise, adjectives I would like to use, but I think the risk of them being interpreted harmfully is too high to use them in this forum. I'm happy to talk more in some other forum if you want.
Re: git: 3d846e48227e - main - Do not forward datagrams originated by link-local addresses
On Wed, May 19, 2021 at 7:33 PM Zhenlei Huang wrote: > > IMHO, I'd like to see the RFC reference remain. I see rgrimes response > > that the RFC's can change with errata and bis docs, but the anchor still > > provides additional context that one can use to learn more about why > > this code exists, and they can chase any future forward references. > RFC's indeed change, and I think it is common in network stack. Then we > need guidelines to better regulate these. CC rgrimes . > Sorry, RFCs themselves do not change -- one of the distinctive features of RFCs is precisely that they are immutable once published. The sentiment that what the current RFC for a given topic is, can change, is something that I can agree with, but that's not quite what was being discussed. -Ben ___ dev-commits-src-main@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/dev-commits-src-main To unsubscribe, send any mail to "dev-commits-src-main-unsubscr...@freebsd.org"
Re: git: 373b95976bce - main - netstat: document that PCB information can't be read from corefiles
On Wed, Apr 19, 2023 at 3:16 AM Michael Tuexen wrote: > The branch main has been updated by tuexen: > > URL: > https://cgit.FreeBSD.org/src/commit/?id=373b95976bcefe2c4b582d6707efc65bae23ea44 > > commit 373b95976bcefe2c4b582d6707efc65bae23ea44 > Author: Michael Tuexen > AuthorDate: 2023-04-19 10:15:35 + > Commit: Michael Tuexen > CommitDate: 2023-04-19 10:15:35 + > > netstat: document that PCB information can't be read from corefiles > > I see only removed lines, other than the .Dd update. Is this the intended change+commit message? -Ben
Re: git: e9e615c88a74 - main - Fix dead references (wrong section) to sysctl(8).
On Fri, Sep 16, 2022 at 11:02 AM Jens Schweikhardt wrote: > The branch main has been updated by schweikh: > > URL: > https://cgit.FreeBSD.org/src/commit/?id=e9e615c88a747587292ea38088ce8bf2f7da4792 > > commit e9e615c88a747587292ea38088ce8bf2f7da4792 > Author: Jens Schweikhardt > AuthorDate: 2022-09-16 18:00:49 + > Commit: Jens Schweikhardt > CommitDate: 2022-09-16 18:00:49 + > > Fix dead references (wrong section) to sysctl(8). > --- > lib/libc/sys/thr_new.2 | 6 +++--- > share/man/man4/iichid.4 | 2 +- > usr.sbin/nfsd/pnfs.4| 2 +- > 3 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/lib/libc/sys/thr_new.2 b/lib/libc/sys/thr_new.2 > index 5516dd1ae4ac..1ef4b8175c77 100644 > --- a/lib/libc/sys/thr_new.2 > +++ b/lib/libc/sys/thr_new.2 > @@ -213,11 +213,11 @@ scheduling policy. > Creation of the new thread would exceed the > .Dv RACCT_NTHR > limit, see > -.Xr racct 2 . > +.Xr rctl_get_racct 2 . > .It Bq Er EPROCLIM > Creation of the new thread would exceed the > .Dv kern.threads.max_threads_per_proc > -.Xr sysctl 2 > +.Xr sysctl 8 > > sysctl(3) might be a more natural analogue than sysctl(8) if the original is sysctl(2). -Ben
Re: git: 2c2ef670a79b - main - pseudofs: use the vget_prep/vget_finish idiom
On Mon, Sep 19, 2022 at 1:09 PM Mateusz Guzik wrote: > The branch main has been updated by mjg: > > URL: > https://cgit.FreeBSD.org/src/commit/?id=2c2ef670a79b7f8fa84796a04885a3f76c914762 > > commit 2c2ef670a79b7f8fa84796a04885a3f76c914762 > Author: Mateusz Guzik > AuthorDate: 2022-09-19 20:07:10 + > Commit: Mateusz Guzik > CommitDate: 2022-09-19 20:08:40 + > > pseudofs: use the vget_prep/vget_finish idiom > > Picking an arbitrary commit to reply to: could you please add a bit more detail about the "why" to commit messages in the future? Having looked a little bit, it seems that this would be "as part of the broader effort to remove the vnode interlock [from a specific class of operations?]". A pointer to a bigger-picture doc would be great as well. I co-maintain an out-of-tree filesystem and commit messages like this make it really hard for me to get a handle on whether I need to do anything and, if so, where to start looking to find out what to do. An overall project page would be a great reference, or even comment around the implementations that points to a key differential revision that implemented the core behavior. One of the things that's been really nice about developing for the FreeBSD VFS in the past is how easy it is to determine what a filesystem implementation needs to provide, and I'd love to see us continue that tradition. Thanks, Ben
Re: git: 2c2ef670a79b - main - pseudofs: use the vget_prep/vget_finish idiom
On Thu, Sep 22, 2022 at 3:11 AM Mateusz Guzik wrote:
> On 9/19/22, Benjamin Kaduk wrote:
> > On Mon, Sep 19, 2022 at 1:09 PM Mateusz Guzik wrote:
> >
> >> The branch main has been updated by mjg:
> >>
> >> URL:
> >>
> https://cgit.FreeBSD.org/src/commit/?id=2c2ef670a79b7f8fa84796a04885a3f76c914762
> >>
> >> commit 2c2ef670a79b7f8fa84796a04885a3f76c914762
> >> Author: Mateusz Guzik
> >> AuthorDate: 2022-09-19 20:07:10 +
> >> Commit: Mateusz Guzik
> >> CommitDate: 2022-09-19 20:08:40 +
> >>
> >> pseudofs: use the vget_prep/vget_finish idiom
> >>
> >>
> >
> > Picking an arbitrary commit to reply to: could you please add a bit more
> > detail about the "why" to commit messages in the future?
> > Having looked a little bit, it seems that this would be "as part of the
> > broader effort to remove the vnode interlock [from a specific class of
> > operations?]". A pointer to a bigger-picture doc would be great as well.
>
> The idiom at hand is over 3 years old now and employing it at this
> point should not require a justification.
>
> One can easily see not taking the interlock is faster both single- and
> multi-threaded, which makes the change worthwhile regardless of
> support for the flag in locking primitives going away or not.
>
>
Maybe you can easily see so, and maybe I can easily see so as well.
But it is not guaranteed to be the case for everyone looking at the commit
history.
The "what" of the commit is contained in the commit itself, but the "why"
can easily
be lost to the depths of time; that is why I see it as more important to
record in the commit
message.
Indeed, when I was left here to guess at the "why", I got it wrong! So is
it so hard to add
another sentence or even a clause like "an easy microoptimization" to the
commit message?
Having some hint at the "why" greatly improves the quality of the record
that is the commit.
> So happens I'm going to keep the flag support in vget itself for the time
> being.
>
> > I co-maintain an out-of-tree filesystem and commit messages like this
> make
> > it really hard for me to get a handle on whether I need to do anything
> and,
> > if so, where to start looking to find out what to do. An overall project
> > page would be a great reference, or even comment around the
> implementations
> > that points to a key differential revision that implemented the core
> > behavior. One of the things that's been really nice about developing for
> > the FreeBSD VFS in the past is how easy it is to determine what a
> > filesystem implementation needs to provide, and I'd love to see us
> continue
> > that tradition.
> >
>
> I'm definitely confused by this comment. VFS has rampant layering
> violations, including wtfs like filesystems sneaking in their own
> changes to cn_flags by literally or-ing into it mid-lookup (recently
> fixed, see 5b5b7e2ca2fa9a2418dd51749f4ef6f881ae7179) or leaking their
> internals out and consequently imposing completely unnecessary
> restrictions on the layer (see a comment above vput_final for an
> example).
>
>
I did not say that the VFS itself was great to develop, but rather that my
experience as a filesystem author has been good ("develop for" vs "develop"
is
an unfortunately subtle distinction in English). I consider my point above
about
including "why" in the commit message to be far more important than this
part,
which was just an attempt to add some motivation as to why I personally
care.
Other people have other good reasons to want to include the "why" in the
commit
message, that I surely did not cover fully here.
> That said, the changes I normally made are either backwards-compatible
> or are guaranteed to blow up at compilation time (or worst case at
> runtime with an assert).
>
>
Okay, thank you for letting me know. It is reassuring for my own personal
situation with OpenAFS.
> I agree some form a general doc would be nice, but between spending
> time writing one or actually getting things done, I chose the latter.
>
>
That's your prerogative, and I won't attempt to force you to do otherwise.
For myself, I find that having even a barebones doc has been incredibly
helpful when I come back to the work 3-5 years down the line, let alone when
I am looking at stuff someone else did 3-5 years previously. Getting
things done
is great, and knowing the overall state of the project as it evolves is
also great.
> There are several filesystems which I have no intent in modifying
> beyond bare minimum to keep them operational, thus general theme of
> backwards compat will continue.
>
>
Okay. Thank you.
-Ben
Re: git: c33509d49a6f - main - gssd: Fix handling of the gssname= NFS mount option
On Sat, Jan 7, 2023 at 1:50 PM Rick Macklem wrote: > The branch main has been updated by rmacklem: > > URL: > https://cgit.FreeBSD.org/src/commit/?id=c33509d49a6fdcf86ef280a78f428d3cb7012c4a > > commit c33509d49a6fdcf86ef280a78f428d3cb7012c4a > Author: Rick Macklem > AuthorDate: 2023-01-07 21:49:25 + > Commit: Rick Macklem > CommitDate: 2023-01-07 21:49:25 + > > gssd: Fix handling of the gssname= NFS mount option > > If an NFS mount using "sec=krb5[ip],gssname=" is > done, the gssd daemon fails. There is a long delay > (several seconds) in the gss_acquire_cred() call and then > it returns success, but the credentials returned are > junk. > > I have no idea how long this has been broken, due to some > change in the Heimdal gssapi library call, but I suspect > it has been quite some time. > > Anyhow, it turns out that replacing the "desired_name" > argument with GSS_C_NO_NAME fixes the problem. > Replacing the argument should not be a problem, since the > TGT for the host based initiator credential in the default > keytab file should be the only TGT in the gssd'd credential > cache (which is not the one for uid 0). > > I will try and determine if FreeBSD13 and/or FreeBSD12 > needs this same fix and will MFC if they need the fix. > > This problem only affected Kerberized NFS mounts when the > "gssname" mount option was used. Other Kerberized NFS > mount cases already used GSS_C_NO_NAME and work ok. > A workaround if you do not have this patch is to do a > "kinit -k host/FQDN" as root on the machine, followed by > the Kerberized NFS mount without the "gssname" mount > option. > > Hi Rick, This doesn't seem like a good long-term fix. If we're going to have a gssname argument, we should actually make it take effect, rather than silently ignoring it, which is what using GSS_C_NO_NAME does (it indicates the use of "any credential", which ends up meaning the default credential when used on a GSS initiator). It should be possible to inspect the "junk" credential from gss_acquire_cred() and learn more about what happened (perhaps a non-kerberos mechanismm was picked, or the name was in the wrong format) using various gss_inquire_*() calls, as a diagnostic measure. Unfortunately I don't anticipate having a huge amount of time to put into it anytime soon... Thanks, Ben
Re: git: c33509d49a6f - main - gssd: Fix handling of the gssname= NFS mount option
Hi Rick, On Tue, Jan 10, 2023 at 08:26:23PM -0800, Rick Macklem wrote: > On Sat, Jan 7, 2023 at 6:04 PM Benjamin Kaduk wrote: > > This doesn't seem like a good long-term fix. > > If we're going to have a gssname argument, we should actually make > > it take effect, rather than silently ignoring it, which is what using > > GSS_C_NO_NAME > > does (it indicates the use of "any credential", which ends up meaning the > > default credential when used on a GSS initiator). > > > > It should be possible to inspect the "junk" credential from > > gss_acquire_cred() > > and learn more about what happened (perhaps a non-kerberos mechanismm was > > picked, or the name was in the wrong format) using various gss_inquire_*() > > calls, > > as a diagnostic measure. Unfortunately I don't anticipate having a huge > > amount of time > > to put into it anytime soon... > > > I found the underlying problem. The upcall RPC from the kernel was timing out > at 25sec and the gss_acquire_cred() call was not done at that time. > (It was close. > gss_acquire_cred() took about 27sec.) Then the kernel code would assume that > the gssd(8) daemon had gone away and closed the upcall socket. This made the > gssd(8) daemon to terminate, due to a SIGPIPE signal. Thanks for digging into this more. Wow, 27 seconds is really long for gss_acquire_cred() in normal operation! Do you happen to have a packet capture including port 88 traffic during this behavior? I kind of have to assume that it is hitting the network to incur such a long delay, as I'm not thinking of anything purely local that would take so long. (Actually, in the original model, this call would not have hit the network at all, with that being deferred until the security-context-establishment calls, but some modern extensions have changed things.) > Increasing the timeout makes it work. > > I am now "on the fence" w.r.t. leaving this patch in. As I noted, I > think it is safe > to do, since the credential cache used by the gssd(8) daemon should only have > a TGT for the host-based client credential. > Without the patch, the mount takes almost 30sec instead of a fraction > of a second > with the patch (assuming the timeout has been increased, which turns out to be > needed for the case where a user's TGT has expired and they attempt to access > the mount). > > If you really think it should be reverted, I can do that. I'm not going to specifically ask for a revert until we've tried a bit more to figure ou the root cause of the issue. The behavior is pretty weird, and I'd like to see more data before making a decision. > Thanks for your comments, rick > ps: I will be committing a change to increase the timeout. I see that, thanks for putting in the additional workaround quickly. Thanks again, Ben
Re: git: 95335dd3c19e - main - rtld: introduce STATIC_TLS_EXTRA
On Mon, Oct 30, 2023 at 10:42 AM Stephen J. Kiernan wrote: > The branch main has been updated by stevek: > > URL: > https://cgit.FreeBSD.org/src/commit/?id=95335dd3c19e0ade161bb4dc8462fc3d045ce4f8 > > commit 95335dd3c19e0ade161bb4dc8462fc3d045ce4f8 > Author: Stephen J. Kiernan > AuthorDate: 2023-10-29 21:13:10 + > Commit: Stephen J. Kiernan > CommitDate: 2023-10-30 17:42:05 + > > rtld: introduce STATIC_TLS_EXTRA > > The new STATIC_TLS_EXTRA variable provides a means for applications > to increases the size of the extra static TLS space allocated by > rtld beyond the default of '128'. This extra static TLS space is used > for objects loaded with dlopen. > > The value specified in the variable must be no less than the default > value and no greater than the maximum allowed value for size_t type. > > I think that we want to have a maximum allowed value that is smaller than SIZE_T_MAX, both to prevent chance of this being used in attacks and to prevent integer overflow. Perhaps something large but not incredibly large, like 1M? > If an invalid value is specified, rtld will ignore it and just use > the default value. > > The rtld(1) man page is updated to document this new option. > > Obtained from: Juniper Networks, Inc. > Differential Revision: https://reviews.freebsd.org/D42025 > --- > libexec/rtld-elf/aarch64/reloc.c | 2 +- > libexec/rtld-elf/amd64/reloc.c | 2 +- > libexec/rtld-elf/arm/reloc.c | 3 ++- > libexec/rtld-elf/i386/reloc.c | 2 +- > libexec/rtld-elf/powerpc/reloc.c | 3 ++- > libexec/rtld-elf/powerpc64/reloc.c | 3 ++- > libexec/rtld-elf/riscv/reloc.c | 2 +- > libexec/rtld-elf/rtld.1| 8 +++- > libexec/rtld-elf/rtld.c| 21 + > libexec/rtld-elf/rtld.h| 1 + > 10 files changed, 35 insertions(+), 12 deletions(-) > > diff --git a/libexec/rtld-elf/aarch64/reloc.c > b/libexec/rtld-elf/aarch64/reloc.c > index c8f09d797215..907377f2619a 100644 > --- a/libexec/rtld-elf/aarch64/reloc.c > +++ b/libexec/rtld-elf/aarch64/reloc.c > @@ -521,7 +521,7 @@ allocate_initial_tls(Obj_Entry *objs) > * use. > */ > tls_static_space = tls_last_offset + tls_last_size + > - RTLD_STATIC_TLS_EXTRA; > + ld_static_tls_extra; > > _tcb_set(allocate_tls(objs, NULL, TLS_TCB_SIZE, TLS_TCB_ALIGN)); > } > diff --git a/libexec/rtld-elf/amd64/reloc.c > b/libexec/rtld-elf/amd64/reloc.c > index ce74c54cc5c3..9c5887def356 100644 > --- a/libexec/rtld-elf/amd64/reloc.c > +++ b/libexec/rtld-elf/amd64/reloc.c > @@ -527,7 +527,7 @@ allocate_initial_tls(Obj_Entry *objs) > * offset allocated so far and adding a bit for dynamic > * modules to use. > */ > - tls_static_space = tls_last_offset + RTLD_STATIC_TLS_EXTRA; > + tls_static_space = tls_last_offset + ld_static_tls_extra; > > This calculation could overflow, as I see it (likewise for the other archs). -Ben
Re: git: 2e2a1c8ecf63 - main - libgssapi: Remove set but unused variable.
On Tue, Jun 20, 2023 at 9:29 AM John Baldwin wrote:
> The branch main has been updated by jhb:
>
> URL:
> https://cgit.FreeBSD.org/src/commit/?id=2e2a1c8ecf639317f40cdb1c2a0c5b9abe990e58
>
> commit 2e2a1c8ecf639317f40cdb1c2a0c5b9abe990e58
> Author: John Baldwin
> AuthorDate: 2023-06-20 16:28:59 +
> Commit: John Baldwin
> CommitDate: 2023-06-20 16:28:59 +
>
> libgssapi: Remove set but unused variable.
>
> Reported by:GCC
> ---
> lib/libgssapi/gss_delete_sec_context.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/lib/libgssapi/gss_delete_sec_context.c
> b/lib/libgssapi/gss_delete_sec_context.c
> index 930f51399cce..b64e32c5dc2c 100644
> --- a/lib/libgssapi/gss_delete_sec_context.c
> +++ b/lib/libgssapi/gss_delete_sec_context.c
> @@ -41,7 +41,6 @@ gss_delete_sec_context(OM_uint32 *minor_status,
> gss_ctx_id_t *context_handle,
> gss_buffer_t output_token)
> {
> - OM_uint32 major_status;
> struct _gss_context *ctx = (struct _gss_context *) *context_handle;
>
> if (output_token)
> @@ -54,7 +53,7 @@ gss_delete_sec_context(OM_uint32 *minor_status,
> * otherwise fake an empty token.
> */
> if (ctx->gc_ctx) {
> - major_status = ctx->gc_mech->gm_delete_sec_context(
> + (void) ctx->gc_mech->gm_delete_sec_context(
>
Looks like gcc was catching a latent bug here -- if we consult the
corresponding heimdal implementation, major_status is initialized to
GSS_S_COMPLETE but this assignment can override it, and the function itself
returns major_status rather than a hardcoded GSS_S_COMPLETE.
-Ben
> minor_status, &ctx->gc_ctx, output_token);
> }
> free(ctx);
>
>
Re: git: b7f2a457a883 - main - arch.7: grammar fixes
On Tue, Feb 4, 2025 at 12:29 PM Maxim Konovalov wrote: > The branch main has been updated by maxim: > > URL: > https://cgit.FreeBSD.org/src/commit/?id=b7f2a457a883c8530c9b6111cee6a988ce5b7249 > > commit b7f2a457a883c8530c9b6111cee6a988ce5b7249 > Author: Maxim Konovalov > AuthorDate: 2025-02-04 20:26:53 + > Commit: Maxim Konovalov > CommitDate: 2025-02-04 20:26:53 + > > arch.7: grammar fixes > > The "for hysterical raisons" was a nice one, though. > > MFC after: 3 days > --- > share/man/man7/arch.7 | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/share/man/man7/arch.7 b/share/man/man7/arch.7 > index a3c875df0bff..796c6db7d299 100644 > --- a/share/man/man7/arch.7 > +++ b/share/man/man7/arch.7 > @@ -352,7 +352,7 @@ userland interfaces relating to underlying hardware > platform > differences in bus architecture, device enumeration and boot interface. > Generally, > .Dv MACHINE > -should only be used in src/sys and src/stand or in system imagers or > +should only be used in src/sys and src/stand or in system images or > installers. > "system imagers" is a real term -- people or scripts who image (i.e., install) systems. I think "imagers" makes more sense than "images" here since the "system image" would typically be a static set of data and the imager is a thing that is potentially dynamic (i.e., needing to control MACHINE or behave differently depending on its value) and the system images that it produce do not gain any value from examining MACHINE). > .It Dv MACHINE_ARCH > Represents the CPU processor architecture. > @@ -414,7 +414,7 @@ in the top level Makefile for cross building. > Unused outside of that scope. > It is not passed down to the rest of the build. > Makefiles outside of the top level should not use it at all (though > -some have their own private copy for hysterical raisons). > +some have their own private copy for historical reasons). > > I agree that "hysterical raisons" is fun but do not propose to revert that part. -Ben
Re: git: c7da9fb90b0b - main - KRB5: Enable MIT KRB5 by default
On Mon, Jul 28, 2025 at 3:04 PM Benjamin Kaduk wrote: > > Note that MIT krb5 provides the gss_krb5_export_lucid_sec_context() API > that does a lot of the work of getting useful bits out of an established > GSS security context. > > And a bit more context on what is going on here and why kgssapi has to care: The GSS-API (RFC 2743) is all about a way to "establish a security context" (i.e., do crypto negotiation, authentication, sometimes authorization, etc.) between two entities, the initiator and the acceprot, and then exchanging protected messages between the two (which can be either encrypted or just integrity protection tags for otherweise cleartext data); later extensions included the ability to produce identical PRF output on both parties, etc.. The details are "mechanism-specific", and for this purpose we're exclusively talking about the krb5 mechanism. The steps to establish the security context are complicated and sometimes fiddly, and in the general case can require a large number of round-trips between the initiator and acceptor before the security context is established. The individual message-protection parts are comparatively simple and amendable to implementation in the kernel for processing efficiency. RFC 2743 also defines functions for GSS_Export_sec_context() and GSS_Import_sec_context(), that are designed essentially to pass information about an established security context from one process to another on the same machine (which are presumably using the same implementation and version of the implementation), so the contents of the exported blob are opaque and implementation-specific. We are abusing that mechanism to export information about the security context that gssd has established and feed that information into the kernel implementation of the per-message processing routines. At present, this necessarily entails knowing the details of the implementation-specific opaque blob that is the "export sec context token", which is what the sys/kgssapi/krb5/krb5_mech.c code is doing. But if we can get the information we want without breaking the abstraction barrier, such as via the gss_krb5_export_lucid_sec_context() API, we are in a more robust posture overall and somewhat future-proofed against future evolution by MIT krb5. (I note that recent Heimdal versions seem to also expose a gss_krb5_export_lucid_sec_context() API, so part of the problem is just that the Heimdal in base is so old.) -Ben
Re: git: c7da9fb90b0b - main - KRB5: Enable MIT KRB5 by default
On Mon, Jul 28, 2025 at 7:04 AM Rick Macklem wrote: > On Mon, Jul 28, 2025 at 1:20 AM Konstantin Belousov > wrote: > > > > CAUTION: This email originated from outside of the University of Guelph. > Do not click links or open attachments unless you recognize the sender and > know the content is safe. If in doubt, forward suspicious emails to > ith...@uoguelph.ca. > > > > On Sun, Jul 27, 2025 at 08:26:03PM -0700, Rick Macklem wrote: > > > On Tue, Jul 22, 2025 at 9:00 AM Cy Schubert > wrote: > > > > > > > > CAUTION: This email originated from outside of the University of > Guelph. Do not click links or open attachments unless you recognize the > sender and know the content is safe. If in doubt, forward suspicious emails > to ith...@uoguelph.ca. > > > > > > > I know diddly about how libraries are handled, but is it possible to > put the > > > old Heimdal 1.5.2 libraries somewhere (semi-private) under different > names? > > > > > > I ask because it is going to be very difficult to port the gssd to the > > > new libraries. > > > > > > The problem is that the KGSSAPI code assumes some stuff very specific > > > to Heimdal. Take a look at sys/kgssapi/krb5/krb5_mech.c and you'll see > > > what I mean. (There's code that parses the keys etc out of the > internally > > > generated tokens. I have no idea where to even find the information on > > > how/where the MIT code hides this stuff and it a large part of > krb5_mech.c > > > looks like it will have to be re-written to work with the MIT > libraries.) > > > > It might be better to extract the required bits and keep just them. > > Perhaps even moving that bits from vendor to FreeBSD-owned code area. > The problem is that the code in sys/kgssapi/krb5/krb5_mech.c does contain > bits extracted from the Heimdal code. Basically, a detailed knowledge of an > internal structure that the keys are extracted from. > --> I am now thinking that adding an upcall to the gssd and letting it > extract > the keys might be a better plan. (At least it moves the maintenance > to > userland and, hopefully, library calls can replace the detailed > knowledge > about the internals of the implementation.) > > Note that MIT krb5 provides the gss_krb5_export_lucid_sec_context() API that does a lot of the work of getting useful bits out of an established GSS security context. > > > > I do not think that keeping large pieces of code in vendor without > updates > > is a good plan. > Agreed. I'll work on it. (But no guarantees w.r.t. timeline.) > > Maybe doing a transition to Heimdal 7.8 (or 8.n) would be less painful? > (It looks like Heimdal is getting maintenance these days. I think Debian > is using it, which suggests it will get at least some TLC?) > > I think adapting this to the MIT krb5 code is feasible. I think that kg_ctx_externalize() is where the actual exported security context token is produced (no structure, just bashing bytes out into the buffer). -Ben
Re: git: c7da9fb90b0b - main - KRB5: Enable MIT KRB5 by default
On Wed, Jul 30, 2025 at 10:36 AM Rick Macklem wrote: > On Mon, Jul 28, 2025 at 3:32 PM Benjamin Kaduk wrote: > > > > On Mon, Jul 28, 2025 at 3:04 PM Benjamin Kaduk > wrote: > >> > >> > >> Note that MIT krb5 provides the gss_krb5_export_lucid_sec_context() API > that does a lot of the work of getting useful bits out of an established > GSS security context. > >> > > > > > > > > > > And a bit more context on what is going on here and why kgssapi has to > care: > > The GSS-API (RFC 2743) is all about a way to "establish a security > context" (i.e., do crypto negotiation, authentication, sometimes > authorization, etc.) between two entities, the initiator and the acceprot, > and then exchanging protected messages between the two (which can be either > encrypted or just integrity protection tags for otherweise cleartext data); > later extensions included the ability to produce identical PRF output on > both parties, etc.. The details are "mechanism-specific", and for this > purpose we're exclusively talking about the krb5 mechanism. The steps to > establish the security context are complicated and sometimes fiddly, and in > the general case can require a large number of round-trips between the > initiator and acceptor before the security context is established. The > individual message-protection parts are comparatively simple and amendable > to implementation in the kernel for processing efficiency. > > RFC 2743 also defines functions for GSS_Export_sec_context() and > GSS_Import_sec_context(), that are designed essentially to pass information > about an established security context from one process to another on the > same machine (which are presumably using the same implementation and > version of the implementation), so the contents of the exported blob are > opaque and implementation-specific. We are abusing that mechanism to > export information about the security context that gssd has established and > feed that information into the kernel implementation of the per-message > processing routines. At present, this necessarily entails knowing the > details of the implementation-specific opaque blob that is the "export sec > context token", which is what the sys/kgssapi/krb5/krb5_mech.c code is > doing. But if we can get the information we want without breaking the > abstraction barrier, such as via the gss_krb5_export_lucid_sec_context() > API, we are in a more robust posture overall and somewhat future-proofed > against future evolution by MIT krb5. > > (I note that recent Heimdal versions seem to also expose a > gss_krb5_export_lucid_sec_context() API, so part of the problem is just > that the Heimdal in base is so old.) > > Well, here's some "not so good" news... > I've been trying to use gss_inquire_sec_context_by_oid(..) with the oid > for the GSS_KRB5_EXPORT_LUCID_SEC_CONTEXT_OID with version 1. > It kept failing. > The problem seems to be that "gctx->proto == 4" in > make_external_lucid_ctx_v1() > function. This function only knows about the 0 and 1 setting for > gctx->proto. > > Any ideas, rick > > I'm not seeing anything to suggest that a "gctx->proto" value of 4 is ever expected; it looks like it's supposed to just be 0 (for the legacy RFC 1964 format) or 1 (for the "CFX" format of RFC 4121, with wider sequence numbers for message-protection formats, etc.). So maybe it's worth posting your current WIP somewhere to take a closer look at what's going on. >From your previous message, > I am working on using gss_inquire_sec_context_by_oid(), which I think is just a front-end to gss_krb5_export_lucid_sec_context()? If that doesn't work, I'll switch to gss_krb5_export_lucid_sec_context(). (I am still waiting for the day when there is another mechanism. I have heard rumblings w.r.t. a mechanism for the Oauth stuff, but as far as I know, about all that they did was define an OID for it.) It looks like a front-end to the same core implementation at least (technically not a wrapper for the public API, though). (There are a bunch of non-krb5 mechanisms, most not in terribly widespread use.) > Btw, do you have any experience porting KDC databases from Heimdal to MIT? (At this point, Cy has done it, but after doing so, the passwords all had to be reset. He thought he had used "--decrypt" when he dumped the Heimdal KDC.) I do not have such experience, but the conventional way to do it involves an unencrypted dump (which I presume is what the aforementioned "--decrypt" does). Heimdal and MIT use (or at least used, the last time I looked) different techniques for encrypting the per-principal data in the dump file, so a trip through plaintext helps. I do remember reading about Heimdal having grown some support for the MIT database format; the commit message at https://github.com/heimdal/heimdal/commit/57f1545a46fdad9207a71903a56f3c1d1fff3a10 is perhaps a very high-level description of what is expected to be possible. -Ben
