FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F14.3 2025-05-13T12:41:32Z 2025-05-13T12:41:32Z Olivier Certner olce@FreeBSD.org 2025-05-06T13:47:18Z urn:sha1:d5fff1aad54c2e5a79d00d5781c9919ad11adcf3 As stated in the previous commit, option '-J' was introduced by commit "Add -J to filter by matching jail IDs and names." (13767130c7147ae7182a, r265229), which unfortunately talked about '-J' being a filter while actually implementing it as a regular selection option which adds to the processes to display. The manual page's formulation hinted more at '-J' being a filter, which it is not, or could be just considered ambiguous, because of the presence of the "only" word. Consequently, remove it and reformulate. Reviewed by: ziaee, dch MFC after: 1 day Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D50194 (cherry picked from commit cbda1aea6532697247bcca6e59d45775857c35e2) (cherry picked from commit 1586fd84fbdab2e2ec205ca717c69946805f2ba0) Approved by: re (cperciva) 2025-05-01T19:48:47Z Olivier Certner olce@FreeBSD.org 2025-04-28T14:58:58Z urn:sha1:11e94e3849f0d9f55a441ddf0206a5f6b4e053e0 Noted by: lwhsu MFC after: 3 days Sponsored by: The FreeBSD Foundation (cherry picked from commit eee8cd8c2d6b3350b1d88e33007f31a1422b8459) 2025-05-01T19:48:47Z Olivier Certner olce@FreeBSD.org 2025-04-28T12:55:00Z urn:sha1:a1abca38f6e1394c142a4d608b04ab918ee152e0 Where appropriate. MFC after: 3 days Sponsored by: The FreeBSD Foundation (cherry picked from commit b222e491178ff46ddec1bded5f3fe597328c85da) 2025-05-01T19:42:25Z Olivier Certner olce@FreeBSD.org 2025-04-01T13:07:24Z urn:sha1:a2132d91739dc22b99e7da836c81962eed47b8f9 This is what POSIX mandates for option '-U' and arguably the behavior that most users actually need in most cases. Before, '-U' would select processes by their effective user IDs (which is the behavior mandated by POSIX for option '-u'). Matching by real user IDs allows to list all processes belonging to the passed users, including those temporarily having a different effective user ID, which can happen if launched by a setuid executable or if using some credentials-changing facility (such as seteuid() for root processes or mac_do(4)/setcred(2)). Conversely, processes temporarily assuming the identity of some of the passed users will not be listed anymore (they do not "belong" to these users). This change also makes '-U' consistent with '-G', the latter already matching on real group IDs. While here, remove the (non-compiled) code for tentative option '-R' as its proposed behavior was the one established here for '-U'. Also, move the compiled-out old code for '-U' under '-u' for reference, as this is what the latter should do according to POSIX, even if it seems unlikely we will want to change the behavior of '-u'. Reviewed by: manpages (ziaee) MFC after: 3 days Relnotes: yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49622 (code) Differential Revision: https://reviews.freebsd.org/D49623 (manual page) (cherry picked from commit 995b690d1398044dc9d85a6d86ec550cda30b2ac) 2025-05-01T19:42:18Z Olivier Certner olce@FreeBSD.org 2025-04-01T11:45:08Z urn:sha1:154ccb0196cd56954b976890acf85cdb2b0fd94c MFC after: 3 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49621 (cherry picked from commit 2d7f70975bd8146f36b35477a8a1be490a0afc95) 2025-05-01T19:37:05Z Olivier Certner olce@FreeBSD.org 2025-04-01T09:47:25Z urn:sha1:1e8dc267ca912a39261627c54573233fbdcfc240 This puts our ps(1) in conformance with POSIX. While here, replace ad-hoc initialization of 'uidlist' with a call to expand_list(). *** Review of the ps(1) implementations in other BSDs, illumos, and Linux's procps shows they already behave as prescribed by POSIX. Previously, we would match processes with their effective user ID but using our real user ID. While the real user ID is meant as the real identity of a process, and is used, e.g., to perform accounting or be permitted to send signals to specific targets, selecting processes to display is arguably more akin to a kind of (advisory) access control. ps(1) is not installed setuid, so normally the real and effective user IDs of ps processes are the same. This may however not be the case when ps(1) is launched by another setuid executable, and the launching process may then logically expect that ps(1) lists the processes corresponding to its effective UID. MFC after: 3 days Relnotes: yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49619 (code) Differential Revision: https://reviews.freebsd.org/D49620 (manual page) (cherry picked from commit 1aabbb25c9f9c4372fd68621f8cabdc10b665527) 2025-05-01T19:37:05Z Olivier Certner olce@FreeBSD.org 2025-03-14T21:42:08Z urn:sha1:1ee62f354ab02e25b8c13b8df331d947aa50dff8 When combined with other options affecting the selection of processes, except for '-X' and '-x', option '-a' would have no effect (and '-A' would reduce to just '-x'). This was in contradiction with the rule applying to all other selection options stating that one process is listed as soon as any of these options has been specified and selects it, which is both mandated by POSIX and arguably a natural expectation. MFC after: 3 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49617 (code) Differential Revision: https://reviews.freebsd.org/D49618 (manual page) (cherry picked from commit 93a94ce731a89b5643021b486da599e7963da232) 2025-05-01T19:37:05Z Olivier Certner olce@FreeBSD.org 2025-03-07T10:50:46Z urn:sha1:1fc8cb547cd4cc1b3476ee3a6ca1d9da5270b2b1 The ps(1) display's list of columns is now first built without taking into account the '-O' options. In a second step, all columns passed via '-O' are finally inserted after the built-so-far display's first PID column (if it exists, else at start), in their order of appearance as arguments to the '-O' options. This new two-step procedure suppresses the following undesirable behaviors: - '-O' used to insert the columns of the default display even if the user also passed other options to request specific columns. - Each occurence of '-O' beyond the first would just insert the passed keywords after those requested by the previous options, as if by '-o', inconsistently with the behavior for the first occurence. These behaviors had more annoying consequences: - Where the columns of some '-O' occurence appear in the display used to depend on the actual position of '-O' with respect to other options, despite the natural expectation that they should go near a single PID column considered as an anchor regardless of other options adding columns. - Columns specified with multiple '-O' options would not be grouped together. - It used to be impossible to specify custom headers but for the last column for columns that are next to each other (i.e., specified by a single '-O' occurence). which are now all lifted. With these changes, '-O' can still be used alone to amend the default display, but can now be used also in conjunction with any specific display, and in particular "canned" ones invoked by '-j', '-l', '-u' or '-v'. ****** This part discusses other ps(1) implementations' behaviors and compares them to the one established by this change. NetBSD seems to be the only other BSD having refined the meaning of ps(1)'s '-O' option. While the behavior there is similar to the new one here on the surface, it differs on the following points: 1. If no options requesting a specific display are present before the first '-O' option, the appearance of '-O' triggers the insertion of the default display, regardless of whether such specific display options appear *after* it. 2. If options requesting a specific display appear before the first '-O' and none specify a PID column, columns listed in the first '-O' are appended to them (as '-o' would do), but columns passed by further '-O' options are then inserted next to the columns of the first '-O' options. Behavior of point 1 seems to have only one advantage: To allow to customize the default display by first using '-O' and then other options appending to it, but as the default display finishes with the COMMAND column, it is unlikely that one wants to use '-o' or other specific display options after '-O' (NetBSD's ps(1) does not suppress duplicate columns). A much simpler and easy-to-understand way to reach that effect in FreeBSD, if it really proves useful, would be to introduce a new explicit option that inserts the default display. The column-appending behavior of the first '-O' option in point 2 can be also achieved by using '-o' instead. As '-O' is used to insert columns after the PID one, which is located near the left in the default and all "canned" displays, we found it more consistent and practical to push its columns completely to the left on the absence of a PID column. The effect of multiple '-O' options in NetBSD when no PID column has been requested beforehand is also cumbersome and inconsistent with the documentation (it is likely a bug). Both NetBSD-specific behaviors exposed above also have the disadvantage that the position of '-O' options with respect to other ones is meaningful in ways that are not obvious and that are arguably not desirable as '-O' is meant to append columns after an anchor (the PID column). Linux's procps-ng's ps(1) is very limited in its handling of '-O', and more generally when mixing options tweaking the display. '-O' causes insertion of the default display (like NetBSD does). If '-o' options are specified, '-O' must come before them. '-O' is not usable with canned display options. Additionally, only one '-O' option may appear on the command line, limiting header customization. The only case in which these implementations and ours behave in the same way with respect to '-O' is if only a single '-O' option and no other options changing the display are specified. MFC after: 3 days Relnotes: yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49615 (code) Differential Revision: https://reviews.freebsd.org/D49616 (manual page) (cherry picked from commit 5dad61d9b949bb859450266c6accebc106f50fcc) 2025-05-01T19:37:04Z Olivier Certner olce@FreeBSD.org 2025-04-01T12:50:26Z urn:sha1:220800ca96bad51a4bbd26f4a21d633c71d8aaf9 Now that removal of non-explicitly-requested duplicate columns work with a O(n) algorithm, remove the ad-hoc optimization of crushing the canned displays' formats after first use and constify their format strings. No functional change intended. This change could also be useful if/when allowing, e.g., to double letters of canned displays to indicate their columns should not be subject to automatic removal of duplicates (e.g., 'ps -ll'). MFC after: 3 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49614 (cherry picked from commit fd6b81712eb9a77bbe484954d18fe1fc4a27116b) 2025-05-01T19:37:04Z Olivier Certner olce@FreeBSD.org 2025-03-10T20:20:43Z urn:sha1:7aa2f4826717b8cd35c58f4ddf05145ffe4dbd39 Before this change, when stacking up more columns in the display through command-line options, if user requested to add some "canned" display (through options '-j', '-l', '-u' or '-v'), columns in it that were "duplicates" of already requested ones (meaning that they share the same keyword, regardless of whether their headers have been customized) were in the end omitted. However, this mechanism did not work the other way around, i.e., requesting some canned display(s) first and then adding some columns that are duplicates (through '-o' or '-O') would not remove them from the canned display. Additionally, it did not take into account keyword aliases (which also lead to displaying the same information). This whole mechanism of removing columns from requested canned displays when there are duplicates is useful in a number of scenarios: 1. When one wants the columns of a canned display, but with some of them in a different order and at the edges of the bulk. This needs the change here to move columns after the bulk (previously, only moving them before the bulk would work). 2. To combine multiple canned displays to get more information without repeating common columns. This part has been working before and this behavior is unchanged. 3. In combination with requesting a canned display and additional columns after it, ensure that a single COMMAND column appears at the end of the display (to benefit from the fact that a last COMMAND column can extend further to the right). Point 2 above implies that, when multiple canned displays are requested, we should keep the leftmost column with same keyword. However, columns requested explicitly by '-o' have priority (as the natural extension of point 1's behavior before this change), and in this case all matching columns in canned displays must be suppressed. To this end, when adding requested options to the display's list, we stop trying to find an earlier matching column (which is incidentally a O(n²) algorithm). Instead, we do a first pass over all requested options once they have all been added to the display's list (in scan_vars()). For each keyword, we note if it was requested at least once explicitly (through '-o' or '-O'), in addition to setting 'needuser' and 'needcomm' (as before). Then, a second pass decides whether to keep each column. A column is removed if it should not be kept absolutely (i.e., it wasn't specified via '-o' or '-O') and there is either a matching column that must be kept (determined during the first pass), or we have seen one already (earlier canned displays take precedence). Matching columns are in fact not only those that have same keywords, but also those that have keywords determined to be aliases to each other. Some previous commits ensured that this determination is O(1) and in practice just a few assembly instructions. find_varentry() has been kept although its last caller has been removed as next commit will reintroduce a call to it. MFC after: 3 days Relnotes: yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D49612 Differential Revision: https://reviews.freebsd.org/D49613 (manual page) (cherry picked from commit cd768a840644ad55029ce9c3d41fc52b5045e0cc)