Re: inetd(8): cmdif as builtin
On 23-06-13 07:45, Brett Lymn wrote: | On Fri, Jun 09, 2023 at 08:47:10AM -0400, Mouse wrote: | > | > In any case, the major issue I would have with it is the lack of | > authentication. But that's so obvious that I assume you would be doing | > something like requiring a password - or doing it only for AF_LOCAL | > sockets and using LOCAL_PEEREID. (This is pretty close to what most of | > my pidconn servers do - they use the pidconn analog of LOCAL_PEEREID to | > verify that the client is either root or the same UID the server is | > running as.) | > | | When this was done in last years GSoC it was a AF_LOCAL socket to | control inetd. I am not sure that inetd having a configuration service | listening on the network is a really good idea - to me, it sounds | dangerous and I am dubious that there are many situations that require | remote configuration of inetd. I agree. If you keep it to AF_UNIX, then you can enforce LOCAL_PEEREID (or SO_PEERCRED or equivalent) checking to ensure that the peer is an appropriate local UID (or GID). You could even have different tiers of control, such as "group X for query status" (e.g., for remote monitoring apps that connect in via SSH or whatever), versus "group Y for admin privs to change status", although that's scope creeping... This reduces the remote attack surface to your operations and management (OAM) / MANO / ... systems. If you need "remote" management, solve it like we do for a lot of other systems and remote in (i.e, ssh) to run as a local user, with the existing remote access controls for that.
Re: mtree(8) vs mtree(5)
On 23-06-01 15:44, Valery Ushakov wrote: | We have mtree(8) man page for our mtree that documents the format of | the mtree spec. We also have an mtree(5) page that documents the | format of the mtree spec, but that pages comes from libarchive. This | is kinda confusing. I agree! | What is the relationship between the two? (libarchive borrowed bsd | code? are they kept in sync?) Can we drop the format description from | mtree(8) and rely on mtree(5) from libarchive? Should we drop the | format description from mtree(8), move it to *our own* mtree(5) and | don't install mtree(5) from libarchive? (We can document any | differences in our mtree(5) b/c we know/control both our own | implementation and also which version of libarchive we ship). It doesn't look like our mtree(8) uses libarchive. Does anything in-tree use libarchive's mtree implementation? In general, I'm all for documenting stuff correctly, and reducing duplication. I don't have a strong opinion on whether we keep our mtree(8) file format documentation within mtree(8) or move to our own mtree(5). If we wrote our own mtree(5) (and didn't install libarchive mtree(5), or installed libarchive mtree(5) with a different name?) we should put some notes how it differs (if at all) from libarchive mtree95).caveats into it. The libarchive mtree(5) doesn't have some of the detailed history that we have in our mtree(8). I'm slightly attached to the latter's Luke.
Re: [RFC] inetd(8) changes proposal
On 23-05-31 13:12, tlaro...@polynum.com wrote: | > Also, on 23-05-30 21:03, tlaro...@polynum.com wrote: | > | (When checking, so even with -C, nothing is written via | > | syslog since, then, inetd is not a daemon but just an utility---a syntax | > | checker---printing messages on stdout or stderr and a inetd daemon could be | > | serving at the very same time: so don't spoil its log.) | > | > I don't consider inetd in "check" mode using syslog (except when in -f | > foreground of course) as "spoil[ing] the log"; the relevant entries will | > have a different process ID in the log and sysadmins and log processors | > are quite familiar with dealing with parallel streams of logs from the | > same service with different process IDs, | | But inetd used in check mode is probably to try to validate a candidate | config in the current process to be written. If it is actually used, | the config parsed will be syslogged when actually loaded. | | So I think when using inetd in check mode, it is an utility and the | config will go to stdout, and the errors about the parsing to stderr | (and when trying to run, the syslog will have only the information about | failure to parse, or success and config dump, not the details of the | parsing since these failures can be explored at length by using inetd in | check mode). IMHO, if check + -f foreground; errors to stdout/stderr, and if check + (background default); output to syslog. In any case, success is 0 status, failure is non-zero (or signal raise). If check mode is used in an rc.d script (for example), dumping a lot of errors to stderr can ruin "clean" rc.d output, and if the stderr errors occur at startup, you may not have easy access to errors printed to stderr on boot, whereas you generally have the syslog. Again, we've found both helpful at work. Originally we used to just print daemon startup errors to stderr. We eventually changed to duplicate to syslog until we know if we're foreground/background mode or not. This isn't a NetBSD convention per se, although I could write up in more detail the conventions we do use and pass them around separately for consideration/refinement for NetBSD services/daemons. Luke.
Re: [RFC] inetd(8) changes proposal
On 23-05-31 12:43, tlaro...@polynum.com wrote: | And I think you're right: the info will go in a 0400 file in /tmp, and | will be a way to obtain various running infos---but for now, just the | running config (it could perhaps be extended, but not now, to add | stats, what is masked by a secmodel etc.) I don't think the data should be written to /tmp; it's world writable, the service often runs as root, and avoiding TOCTOU security problems is error prone. If you want to write the validated configuration to a file, one of: 1. Compiled in default to a inetd-specific path that's has restricted write access (e.g., a /var/*) 2. Provide CLI option and/or configuration option for the path, although the config option may cause circular issues when you're trying to parse the configuration to learn where to write the configuration. Luke.
Re: [RFC] inetd(8) changes proposal
On 23-05-31 03:54, Robert Elz wrote: | Date:Tue, 30 May 2023 21:03:21 +0200 | From:tlaro...@polynum.com | Message-ID: | | | Do you think that SIGINFO is sound as the signal to obtain a config DUMP in | | the syslog? | | First, dumping config to syslog seems like an odd thing to do at all, I'd | normally expect it to be dumped in a file instead (something in /tmp | perhaps, or where defined in the config file perhaps), Over years of developing and maintaining various long-running services/daemons on various work systems that run for long periods of time, we've developed a convention to log a bunch of pertinent configuration on startup, and when the configuration reloads (if reload is supported) - either via SIGHUP or dynamically when configuration changes, depending upon the service and its implementation history. In some cases we just log what's change from compiled-in defaults (on startup) or changes from previous configuration before the reload. Working with our support team and customers we've found that the practice of having such configuration in the log with the other messages from the service is quite helpful for debugging issues or confirming configuration especially if it's been running for a long time and the configuration has been changed since startup (without a reload). We also have a convention of logging a "starting" event once the service has validated its options and configuration and is about to actually start work, "stopping" when shutting down (with a summary of the error that triggered it, if any - more details of the event is usually found in a previous log message), or "terminating by signal %d" if a signal (with appropriate set default handler and re-raise of re-raise of the signal, so that ^C in a shell loop actually stops). These conventions may be useful here, or not. Just food for thought. YMMV :) | But that's independent of the signal used to make it happen, that | could be SIGINFO, which normally makes a process list its current | state (what it is doing) - and for that knowing what config inet is | serving could be considered part - but that is also typically a lot | more than SIGINFO generates (usually just a line). Personally | I'd probably pick a different signal for that, but I am not sure which. Yes, SIGINFO is really intended for foreground apps receiving a signal from the tty (e.g., I use ^T in tcsh) to display a short line with status, rather than services/daemons logging to syslog. E.g., lukem% ^T [ 6909969.1505419] load: 0.00 cmd: tcsh 2750 [0x4bb99a/4] 0.31u 0.28s 0% 1456k SIGINFO support has been added to various other applications over the years: dump, gzip, ftp (etc). According to CHANGES.prev I sent a patch to implement TIOCSTAT in the tty driver in ~ 1993, but I don't recall what inspired that patch; maybe it was just tcsh's optional support for SIGINFO / TIOCSTAT. (I certainly didn't invent the idea). As to what signal to use. Maybe USR1 ? Or just leverage off the idea to log on (re)load the pertinent configuration. Maybe add a -D flag to enable debug without foreground (-d enables debug and foreground together), and then dump all the configuration. Also, on 23-05-30 21:03, tlaro...@polynum.com wrote: | (When checking, so even with -C, nothing is written via | syslog since, then, inetd is not a daemon but just an utility---a syntax | checker---printing messages on stdout or stderr and a inetd daemon could be | serving at the very same time: so don't spoil its log.) I don't consider inetd in "check" mode using syslog (except when in -f foreground of course) as "spoil[ing] the log"; the relevant entries will have a different process ID in the log and sysadmins and log processors are quite familiar with dealing with parallel streams of logs from the same service with different process IDs, cheers, Luke.
Re: inetd enhancements - config syntax
On 21-01-31 18:12, David Holland wrote: | Alternatively you could put the glob in the include explicitly | (that is, "include dir/*.conf" That seems the sanest to me too; it's explicit, and it's also following a well-established pattern used by other applications, including: dovecot, (apache) httpd, rsyslogd. The include syntax may differ, the pattern is the same; include a path that supports globbing. Luke.
Re: style change: explicitly permit braces for single statements
I've decided not to pursue this any further.
No objections if anyone else wants to take up the cause.
On 20-07-17 23:20, Alistair Crooks wrote:
| Just to get back to the original subject - fully support {} around single
| statements - have been doing that in my own code for ages.
|
| Would be great to have that codified (ha!)
|
| On Thu, 16 Jul 2020 at 12:01, Rhialto wrote:
|
| > On Thu 16 Jul 2020 at 13:08:49 -0400, Ted Lemon wrote:
| > > It sounds like we need a better tool. FWIW, when actually working on
| > > code, I've found that 120 is a better width than 80 -- with 80, there
are
| > > just too many line breaks. But I don't mean to say that your
| > > preference is wrong -- what sucks is that we have to compromise, instead
| > > of having tools that present the text the way that we want to consume
| > > it without changing anything in the underlying file. E.g. web browsers
| > > just reflow the text when you change the window width. Why don't we
| > > have this for code editors?
| >
| > I have seen an editor (I think it was google's Android development
| > environment) that even went so far as to recognize some particular
| > boilerplate Java code fragments, and abbreviated them. You could unfold
| > them if you wanted though.
| >
| > I wasn't sure if I liked that or hated it.
| >
| > -Olaf.
| > --
| > Olaf 'Rhialto' Seibert -- rhialto at falu dot nl
| > ___ Anyone who is capable of getting themselves made President should on
| > \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG"
| >
Re: style change: explicitly permit braces for single statements
On 20-07-12 10:01, Luke Mewburn wrote: | I propose that the NetBSD C style guide in to /usr/share/misc/style | is reworded to more explicitly permit braces around single statements, | instead of the current discourgement. | | IMHO, permitting braces to be consistently used: | - Adds to clarity of intent. | - Aids code review. | - Avoids gotofail: https://en.wikipedia.org/wiki/Unreachable_code#goto_fail_bug | | regards, | Luke. I was asked to CC this thread to tech-kern@, so I'm doing that. pgpMR7a2z_5TG.pgp Description: PGP signature
style change: explicitly permit braces for single statements
I propose that the NetBSD C style guide in to /usr/share/misc/style is reworded to more explicitly permit braces around single statements, instead of the current discourgement. IMHO, permitting braces to be consistently used: - Adds to clarity of intent. - Aids code review. - Avoids gotofail: https://en.wikipedia.org/wiki/Unreachable_code#goto_fail_bug regards, Luke. pgpdXVyX2q3Ef.pgp Description: PGP signature
