Signify option semantics
Hello all, I've been reading into the signify(1) program a little recently, and the manual page mentons the '-t' option, which is used to ensure the public key deduced from the signature comment "matches /etc/signify/*-keytype.pub", where 'keytype' is the argument given to '-t'. I'm not sure what this means. I've taken a glance over the source code, and it looks like specifying this option is simply intended to ensure that the path to the public key used to verify the given signature matches the path mentioned in the manual page. Is this a correct interpretation? What's the rationale behind this option? Cheers.
Re: Verified auth tty ioctl()s implementation details
On Mon, Jul 17, 2017 at 04:39:10PM -0400, Ted Unangst wrote: > Yes, the difference is intentional. For pretty much exactly the reason you > noticed, although perhaps with the opposite result. A successful > authentication is not meant to be inherited by any random program or script > you run. A) because vague security concerns, but also B) because I think it's > weird that a script maybe works if it runs fast enough, but fails if it takes > five minutes to get to doas. Like "make; doas make install" works on a fast > machine but fails unexectedly on a slower machine. > > A more robust approach to this problem is to invert privilege. Start as root, > then drop to another user. Thank you for explaining; I suspected the reasoning was such. Speaking specifically about ports, is there a way to start a port build as root and then drop priviledges (in a similar manner to the base system's build infrastructure)? A quick glance through bsd.port.mk(5) suggests that this isn't (yet) possible. (A possible workaround is to run "make fetch" as a normal user, "make prepare" as root and "make build" as normal user etc, however if there are dependencies which need to be built at the "make prepare" stage then they are built as root.) Regards
Verified auth tty ioctl()s implementation details
Hi all, In the last couple of days I've been studying sudo(8) and doas(1) to find out how they work and what their operational differences are. With regards to storing persistent cookies, to allow a user to execute further commands without reauthentication (subject to a timeout), sudo uses a timestamp file and doas uses verified auth ioctls on the controlling tty. However, sudo and doas differ in the information stored in the persistent cookie. sudo records the ID of the foreground process group on the controlling terminal while doas records the parent process ID, according to the description of TIOCSETVERAUTH in tty(4). >From an end-user standpoint, this means that if a user has run a priviledged command using sudo and then (within the timeout) runs a script which itself calls sudo, then they will not be prompted to enter a password as the script is running with the same foreground process group on the controlling terminal as the first invocation. However, in the same scenario, doas would prompt for a password when it is invoked from within the script, as its parent process ID is different when running under an interactive user shell from when it's executed in a shell script. (This can also be observed when building ports with SUDO=doas, as doas is invoked at various points in the build process under different make (sub)processes, which results in doas prompting for a password many times.) Now, I am running on the assumption that these ioctl()s were implemented as a kernel-side component of doas's "password timeout" functionality as observed when using the "persist" configuration keyword. From that, my question is whether there is any particular reason for recording the parent process ID in particular as part of the cookie stored by the persistent authentication ioctl() as opposed to the process group ID of the calling process's session leader, as with sudo. Regards.
Re: Audio playback issue on old Thinkpad
On Wed, May 17, 2017 at 05:25:14PM +0200, Alexandre Ratchov wrote:
> On Wed, May 17, 2017 at 02:27:38PM +0100, multiplex'd wrote:
> > Hello all,
> >
> > I have an IBM T22 Thinkpad running OpenBSD 6.1. Recently, I've been trying
> > to play audio on the system but I've run into some trouble.
> >
> > I'm using mplayer from packages, but when I try to play an audio file the
> > playback is extremely slow and of very poor quality (changing the format of
> > the audio file used does not change this behaviour). However, if I start
> > disk-heavy activity at the same time, such as running 'ncdu' (from packages)
> > or 'find /' then suddenly playback is normal and as expected until mplayer
> > spontaneously catches signal 13 (SIGPIPE according to
> > /usr/include/sys/signal.h).
>
> could you provide the output of dmesg ?
dmesg attached below.
OpenBSD 6.1 (GENERIC) #2: Sat May 6 09:37:02 CEST 2017
rob...@syspatch-61-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium III ("GenuineIntel" 686-class) 320 MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,SSE,PERF
real mem = 536231936 (511MB)
avail mem = 513253376 (489MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 04/27/04, BIOS32 rev. 0 @ 0xfd820, SMBIOS rev. 2.3 @
0x1fff (46 entries)
bios0: vendor IBM version "16ET32WW (1.12 )" date 04/27/2004
bios0: IBM 26474CG
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP BOOT
acpi0: wakeup devices LID_(S3) SLPB(S3) PCI0(S4) USB_(S1) UART(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (AGP_)
acpiec0 at acpi0
acpipwrres0 at acpi0: PSER, resource for UART
acpipwrres1 at acpi0: PSIO, resource for FDC_, UART, LPT_, ECP_, FIR_
acpitz0 at acpi0: critical temperature is 97 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
"PNP0303" at acpi0 not configured
"IBM3780" at acpi0 not configured
"PNP0501" at acpi0 not configured
"PNP0400" at acpi0 not configured
"IBM0071" at acpi0 not configured
acpibat0 at acpi0: BAT0 model "ThinkPad Battery" type LION oem "IBM Corporation
"
acpibat1 at acpi0: BAT1 model "ThinkPad Battery" type LION oem "IBM Corporation
"
acpiac0 at acpi0: AC unit offline
"IBM0068" at acpi0 not configured
acpidock0 at acpi0: DOCK not docked (0)
acpivideo0 at acpi0: VID_
bios0: ROM list: 0xc/0xc000 0xcc000/0x1800 0xdc000/0x4000! 0xe/0x1
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x03
intelagp0 at pchb0
agp0 at intelagp0: aperture at 0xf800, size 0x400
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x03
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "S3 Savage/IX-MV" rev 0x13
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
cbb0 at pci0 dev 2 function 0 "TI PCI1450 CardBus" rev 0x03: irq 11
cbb1 at pci0 dev 2 function 1 "TI PCI1450 CardBus" rev 0x03: irq 11
fxp0 at pci0 dev 3 function 0 "Intel 8255x" rev 0x0c, i82550: irq 11, address
00:03:47:b9:1f:6b
inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4
"AT/Lucent LTMODEM" rev 0x01 at pci0 dev 3 function 1 not configured
clcs0 at pci0 dev 5 function 0 "Cirrus Logic CS4280/46xx CrystalClear" rev
0x01: irq 11
ac97: codec id 0x43525914 (Cirrus Logic CS4297A rev 4)
ac97: codec features headphone, 20 bit DAC, 18 bit ADC, Crystal Semi 3D
piixpcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x02: SpeedStep
pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 28615MB, 58605120 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 disabled (no drives)
uhci0 at pci0 dev 7 function 2 "Intel 82371AB USB" rev 0x01: irq 11
piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x03: SMI
iic0 at piixpm0
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 2 device 0 cacheline 0x8, lattimer 0xb0
pcmcia0 at cardslot0
cardslot1 at cbb1 slot 1 flags 0
cardbus1 at cardslot1: bus 5 device 0 cacheline 0x8, lattimer 0xb0
pcmcia1 at cardslot1
isa0 at piixpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
Audio playback issue on old Thinkpad
Hello all, I have an IBM T22 Thinkpad running OpenBSD 6.1. Recently, I've been trying to play audio on the system but I've run into some trouble. I'm using mplayer from packages, but when I try to play an audio file the playback is extremely slow and of very poor quality (changing the format of the audio file used does not change this behaviour). However, if I start disk-heavy activity at the same time, such as running 'ncdu' (from packages) or 'find /' then suddenly playback is normal and as expected until mplayer spontaneously catches signal 13 (SIGPIPE according to /usr/include/sys/signal.h). I suspected that this may be due to the disk being very slow so I tried copying the audio file to an mfs mountpoint and playing from there, however this did not cause any difference in behaviour. I also tried changing the sample rate and frequency both in mplayer and with audioctl, but this also failed to solve the issue. Does anyone have any advice on how to resolve this issue? The hardware is 15 years old and it would be nice to get some more use out of it. Thanks, multiplex'd
Status of OpenCVS
Hello all, I recently stumbled across the OpenCVS webpages and I was wondering what the status of the project is. The webpage says that it is to be released soon, however commits to the CVS tree seem to be few and far between. Is the codebase in a state where it could be ported to other operating systems yet? Thanks, multiplex'd
