pkg_info(1) man page possible error
Hello, I am running OpenBSD in a virtualbox because I am taking a deeper look into it. I was looking for a list of ports packages and read the man page pkg_info(1). That man page it states, "When browsing through uninstalled packages, running pkg_info -I *.tgz will report a summary line for each package [...]" Note the capital eye 'I'. It says so in the VMs man page as well as at https://man.openbsd.org/pkg_info (All Sections ; All Architectures ; OpenBSD-current) (Timestamp: approx. Fri 24 Jan 2020 10:05:00 PM UTC) When I run the command # pkg_info -I *.tgz I get the result Invalid spec: *.tgz Invalid spec: *.tgz # If I run # pkg_info -l *.tgz # NOTE the little ell instead of capital eye I get something that looks like the list the man page describes. Two columns, first being package name and second being a short one line description. If I run # pkg_info -I I get the result pkg_info: Missing package name(s) Usage: <...> Searching for "openbsd pkg_info -I" with duckduckgo just presented the OpenBSD FAQ and Manual Pages and something about a pkg_info -Q bug. I read the man page's descriptions for options -I and -l and it seems to me that -I (capital eye) *should* work the way the man page exemplifies its use or maybe even without an argument. Maybe I am misinterpreting the descriptions. I do not quite understand why requesting the list of packages including a short description works with -l (small ell), which takes a string as an argument. What other information can I provide to clarify where the problem lies? (It may be the man page, pkg_info, "layer 8" or a combination of these three factors.) # uname -a OpenBSD 6.6 GENERIC#4 amd64 Thank you for your time, Andrew Easton
Re: FreeBSD daemon(8)-like command for OpenBSD
On Fri, Jan 31, 2020 at 10:47:17AM +0100, Patrick Kristiansen wrote: > On Fri, Jan 31, 2020, at 09:29, Janne Johansson wrote: > > Den tors 30 jan. 2020 kl 21:08 skrev Patrick Kristiansen > > : > > > > Properly starting up a daemon process requires several steps, > > > > often involving unveil(2), pledge(2), chroot(2), prviledge > > > > dropping, sometimes fork+exec for privilege separation, and so on > > > > > > The process I need to run is written in Clojure and thus runs on the > > > Java Virtual Machine. Do you have any suggestions on how to best go > > > about making it "daemon-like"? I am not sure that I can call unveil(2), > > > pledge(2) and chroot(2) from Clojure without some strange sorcery. > > > > So not related to only Clojure but rather on runtimes that are large > > and unwieldy, this seems to be exactly why plegde() and unveil() came > > into being in the first place, after seeing things that needs to do > > certain privileged operations at some early point, but because of > > design/runtime/hard-to-pledge or whatever has to run with the sum of > > all privileges, all capabilities at all times and at the same time > > being exposed to potential hostile data. > > Yes. I completely understand the motivation behind pledge, unveil and > similar constructs. I also understand that it sort of runs counter to > using one of the world's most secure-by-default operating systems if you > then run an insecure monstrosity on top of it. I was just starting to > like the OpenBSD experience as a user and sysadmin. :-) > > But I also think that it is unrealistic to expect applications to be > written to the same standard as OpenBSD, given the resources needed for > that. Many startups would never get off the ground if that were the > case. > > > I can fully see why Ingo would say "I would not run things like that > > exposed", partly because I figure he actually has a choice to not do > > it, but regardless of what electric fences you like (Selinux, > > capsicum, pledge/unveil, chroots) if you create a huge monolith > > running in an environment which actively prevents you from activating > > any kinds of protections, then I can see how you would see some > > friction. > > I would like to get more information about doing application programming > for an OS like OpenBSD. I understand that if you program your > applications in C, you have readily available pledge/unveil, etc. But > many applications are written in higher-level languages, and in my case > at least, it seems to be nearly impossible to write a secure application > without changing to C or some other language that can easily use > OpenBSD's system calls. And for a mediocre programmer, or just an > inexperienced one, it exposes you to a whole host of other problems that > can lead to worse security and quality. > > The solution is probably just to be a good programmer. ;-) > For the record, I am also interested in information on how pledge(2) and unveil(2) would interact with a "higher level language". I would also be happy to learn more about how they interact with assembly. My conceptual understanding can probably still be improved upon. In the spirit of not demanding to much time from my contemporaries I am especially greatful for pointers to conceptual documentation and to implementation documentation. I have the impression that it seems effective to get a conceptual overview first. [[ I have the suspicion that being a good programmer crucially depends on having conceptual understanding. Maybe it also depends on practice.]] Concretely: Just to start off easy, how can I find conceptual documentation on what an operating system "process" is in OpenBSD and how deeply a libc is tied into that by design? As far as I am aware a process has the "current working directory" associated with it, in order to be able to resolve relative paths and is also where "environment variables" are stored. These remind me of dynamic bindings, at least in spirit. I am only aware of plain C having lexical bindings, in contrast to this. (I am also still fuzzy on how intertwined an operating system and a CPU are. From my superficial understanding, e.g. the operating system has to be aware of the MMU. I am concretely speaking of amd64 territory here.) https://man.openbsd.org/process : did not turn up anything https://man.openbsd.org/pledge : where is further information on what a process is? https://man.openbsd.org/unveil : where is further information on what a process is? Best Regards, Andrew
pkg_info(1) manpage issue
Hello everyone, it appears that there may be a way to misinterpret the man page for pkg_info(1) in the state of commit 0b249e2164be2385bc6a5e82814435649b2b06e0 Date: Sun Jan 24 10:21:43 2021 + on the github openbsd src mirror. The problem description is under the headline "Issue". There is a realistic chance that I am misunderstanding something. If this is the case, what further measures can I take to narrow down the problem? === Issue === The uninstalled packages are supposed to be listed together with their one-line summary. The manual page accessible with $ man 1 pkg_info; reads: [quote] When browsing through uninstalled packages, running pkg_info -I *.tgz will report a summary line for each package, so that it is possible to run pkg_info pkgname.tgz to obtain a longer package description, and pkg_add -n pkgname.tgz to check that the installation would proceed cleanly, including dependencies. [\quote] Copy-pasting the command "pkg_info -I *.tgz" from the manual page into the terminal yields the following error: computer$ pkg_info -I *.tgz Invalid spec: *.tgz Invalid spec: *.tgz computer$ Even calling pkg_info(1) with doas(1) yields the same behaviour: computer$ doas pkg_info -I *.tgz Invalid spec: *.tgz Invalid spec: *.tgz computer$ Note that there is a relatively long pause between the two "Invalid spec" messages both with and without doas(1). In which way am I misunderstanding the manual page for pkg_info(1) for the specific operation of browsing uninstalled packages and showing a summary line? === Affected Man-Page File === /usr.sbin/pkg_add/pkg_info.1 in commit 0b249e2164be2385bc6a5e82814435649b2b06e0 Date: Sun Jan 24 10:21:43 2021 + Kind regards, Andrew Easton
boot_config(8) man page issue; and possibly openbsd.org/report.html
Hello everyone, it appears that there may be a way to misinterpret the man page for boot_config(8) in the state of commit 0b249e2164be2385bc6a5e82814435649b2b06e0 Date: Sun Jan 24 10:21:43 2021 + on the github openbsd src mirror. The problem description is under the headline "Issue". There is a realistic chance that I am misunderstanding something. If this is the case, what further measures can I take to narrow down the problem? === Issue === The boot_config(8) man page reads: [quote] The Ethernet card is not detected at boot because the kernel configuration does not match the physical hardware configuration, e.g. wrong IRQ in OpenBSD/i386. [...] UKC> find ne [...] 25 ne1 at isa0 port 0x300 size 0 iomem -1 iosiz 0 irq 10 drq -1 drq2 -1 flags 0x0 [...] ne1 seems to match the configuration except it uses IRQ 5 instead of IRQ 10. [...] UKC> change ne1 [...] irq [10] ? 5 [\quote] Note, that the line that is longer than 72 characters in this email is also longer than 72 characters in the original manual page. I selfishly chose a more accurate quote of the manual page over breaking the line. Plese let me know, in case this is a serious problem. Maybe https://www.openbsd.org/report.html should be augmented to refer to this specific quotation problem, in case it is important enough to document properly. The sentence "ne1 seems to match the configuration except it uses IRQ 5 instead of IRQ 10" has two ways of being interpreted: (1) the kernel configuration is using IRQ 5 and (2) the hardware configuration is using IRQ 5. After having misunderstood the sentence by assuming meaning (1) and noticing the inconsintency with the other relevant lines in the above quote of the man page, I suggest clarifying the sentence like so (change marked with square brackets): "ne1 seems to match the configuration except it [is supposed to use] IRQ 5 instead of IRQ 10" . One even more explicit option is: "ne1 [in the kernel configuration] seems to match [the hardware] configuration except [for the IRQ being used. The kernel currently uses IRQ 10 and the hardware uses IRQ 5, so the kernel configuration needs to be adjusted to match the hardware configuration.]" I want to thank the tireless efforts which have gone and are currently going into maintaining the exceptionally high documentation standards of OpenBSD. In case my suggestions above are overly pedantic, I sincerely apologize. === Affected Man Page File === /share/man/man8/boot_config.8 in commit 0b249e2164be2385bc6a5e82814435649b2b06e0 Date: Sun Jan 24 10:21:43 2021 + Thank you very much for your time. Kind regards, Andrew Easton
