Re: ratble and rdomain support on dhcpd and openvpn

[Pierre Emeriaud]

2016-07-13 1:37 GMT+02:00 Difan Zhao :
> Thank you Chris! I come from the Cisco world with a little Linux experience 
> but It does make sense to me. It looks like I could run two DHCP processes 
> this way.
>
> However the problem is that I still can't set the rtable.. Also tried the 
> "rdomain" but got the same error. It took the "set flag" command though. I 
> also tried "rcctl set dhcpd200 status on" and it took it too.
>
> Is it problem with my openbsd or dhcpd version?

rcctl table needs a fairly recent openbsd. Not sure if it was already
in 5.9, I'm using -current.

Re: syslog-ng on OpenBSD 5.9

[fRANz]

On Wed, Jul 13, 2016 at 3:54 AM, Nathan Wheeler  wrote:

> With the changes in 5.6 using sendsyslog(2), only syslogd picks up
> local syslog. Search the openbsd-ports list for syslog-ng to see some
> comments on it.

I'll do that Nathan,
thank you for the tip.
-f

Re: syslog-ng on OpenBSD 5.9

[Nathan Wheeler]

With the changes in 5.6 using sendsyslog(2), only syslogd picks up
local syslog. Search the openbsd-ports list for syslog-ng to see some
comments on it.

Re: uefi boot

[YASUOKA Masahiko]

Hi,

On Tue, 12 Jul 2016 21:17:20 -0300
Friedrich Locke  wrote:
> I wonder if that's possible to boot obsd amd64 5.9 CD on a computer whose
> bios is setted to boot UEFI secure mode off.

5.9 CD doesn't support UEFI boot.  If the computer doesn't have legacy
mode BIOS, you need to use an USB memory stick and install59.fs for
this moment.

--yasuoka

uefi boot

[Friedrich Locke]

Hi folks!

I wonder if that's possible to boot obsd amd64 5.9 CD on a computer whose
bios is setted to boot UEFI secure mode off.

Thanks a lot.

Re: ratble and rdomain support on dhcpd and openvpn

[Difan Zhao]

Thank you Chris! I come from the Cisco world with a little Linux experience
but It does make sense to me. It looks like I could run two DHCP processes
this way.

However the problem is that I still can't set the rtable.. Also tried the
"rdomain" but got the same error. It took the "set flag" command though. I
also tried "rcctl set dhcpd200 status on" and it took it too.

Is it problem with my openbsd or dhcpd version?

Thanks,
Difan

-Original Message-
From: Chris Cappuccio [mailto:ch...@nmedia.net]
Sent: Tuesday, July 12, 2016 10:25 AM
To: Difan Zhao 
Cc: Pierre Emeriaud ; misc@openbsd.org
Subject: Re: ratble and rdomain support on dhcpd and openvpn

Difan Zhao [difan.z...@pason.com] wrote:
> Thanks Pierre! However the command does not work for me... Do I need to
upgrade my openbsd box? I am on 5.8 right now.
>
> # rcctl set dhcpd rtable 200
> usage: rcctl [-df] action|get|getdef|ls|order|set
> [service | daemon [variable [arguments]] | daemons |
> lsarg] # rcctl get dhcpd dhcpd_class=daemon
> dhcpd_flags=vr1
> dhcpd_timeout=30
> dhcpd_user=root
>
> If it works, does it mean that dhcpd will only operate on rtable 200? It
will be nice if it can run on both rtable 200 and the default rtable 0...
>

I believe under -current, you'd just:

ln -s /etc/rc.d/dhcpd /etc/rc.d/dhcpd200

rcctl set dhcpd200 rtable 200
rcctl set dhcpd200 flags "-f /etc/dhcpd.conf.200"

and use dhcpd200 and /etc/dhcpd.conf.200 to start for rtable 200, use dhcpd
and /etc/dhcpd.conf for rtable 0

Chris

Re: Sleep, Thinkpad x250

[Donald Allen]

On Tue, Jul 12, 2016 at 4:17 PM, Mike Larkin  wrote:
> On Tue, Jul 12, 2016 at 02:50:33PM -0400, Donald Allen wrote:
>> I have a Thinkpad x250 running 5.9 stable, up-to-date. This system
>> will not re-awaken from sleep mode. No response to the power button --
>> it just continues to sit there slowly blinking and does not respond to
>> pings. Power cycling is the only way I've found to recover. dmesg
>> below. I believe this is one of the Broadwell cpus Ted Unangst
>> mentions in his blog post on OpenBSD and laptops.
>>
>
> Starting with the x240, you need to disable the TPM in the BIOS for
> resume to work. This applies to other models in the same line as well
> (eg, t440, t450, etc).
>
> Try that and see if it fixes things.

It does. Thanks very much!

/Don

Re: producing SHA256 & release(8)?

[Theo de Raadt]

>While this is not a showstopper & can easily be worked around, it seems
>there is a mismatch between what the code does & what the manpage
>specifies.  Is the intent now that building the system & xenocara releases
>be done in separate directories, or should redirection be changed to
>appending in the code?

They have needed to be built in seperate directories for around 3 years.

syslog-ng on OpenBSD 5.9

[fRANz]

Hi all,
I switched from syslogd to syslog-ng (from package,
syslog-ng-3.6.4.tgz) on a amd64 board but now logging of local events
don't works.
Logging of remote events (UDP) works fine.
Only syslog-ng log statistics are recorded to log files, nothing else.

I tried both configurations:

source s_local {
unix-dgram ("/dev/log");
pipe("/dev/klog" log_prefix("kernel: "));
internal();
};

and

source s_local {
   internal();
   file("/dev/klog" program_override("kernel: "));
   unix-dgram("/dev/log");
};

without success.

More details about the system:

#

$ uname -a
OpenBSD ap.ca.fr.lo 5.9 GENERIC.MP#1888 amd64

$ cat /etc/syslog-ng/syslog-ng.conf
# syslog-ng configuration file for OpenBSD.
# This should provide the same behavior as OpenBSD's syslog.conf(5).
# 2010-07-18 ste...@openbsd.org

@version: 3.6

options {
use_dns(no);
create_dirs(no);
keep_hostname(yes);
};

source s_local {
unix-dgram ("/dev/log");
pipe("/dev/klog" log_prefix("kernel: "));
internal();
};

#source s_local_all {
#   unix-dgram ("/dev/log");
#   unix-dgram ("/var/empty/dev/log");
#   unix-dgram ("/var/www/dev/log");
#   internal();
#};

source s_net {
udp(port(514));
};

destination d_console   { file("/dev/console"); };
destination d_messages  { file("/var/log/messages" owner(root)
group(wheel) perm(0644));};
destination d_authlog   { file("/var/log/authlog" owner(root)
group(wheel) perm(0640)); };
destination d_secure{ file("/var/log/secure" owner(root)
group(wheel) perm(0600));  };
destination d_cronlog   { file("/var/cron/log" owner(root)
group(wheel) perm(0600));};
destination d_daemon{ file("/var/log/daemon" owner(root)
group(wheel) perm(0640));  };
destination d_xferlog   { file("/var/log/xferlog" owner(root)
group(wheel) perm(0640)); };
destination d_lpderrs   { file("/var/log/lpd-errs" owner(root)
group(wheel) perm(0640));};
destination d_maillog   { file("/var/log/maillog" owner(root)
group(wheel) perm(0600)); };
destination d_uucplog   { file("/var/log/uucp" owner(uucp)
group(dialer) perm(0660));   };
destination d_doaslog   { file("/var/log/doas");};
destination d_ttyall{ usertty("*"); };
destination d_ttyroot   { usertty("root");  };
destination d_loghost   { udp("loghost" port(514)); };
destination d_857   { file("/var/log/857" owner(root) group(wheel)
perm(0640)); };

filter f_notice {
level(notice .. emerg)
and not(facility(auth,authpriv,cron,ftp,kern,lpr,mail,user));
};
filter f_kerndebug {
level(debug .. emerg) and facility(kern);
};
filter f_msginfo {
level(info .. emerg) and facility(syslog,user);
};
filter f_authinfo {
level(info .. emerg) and facility(auth);
};
filter f_authprivdebug {
level(debug .. emerg) and facility(authpriv);
};
filter f_croninfo {
level(info .. emerg) and facility(cron);
};
filter f_daemoninfo {
level(info .. emerg) and facility(daemon);
};
filter f_ftpinfo {
level(info .. emerg) and facility(ftp);
};
filter f_lprdebug {
level(debug .. emerg) and facility(lpr);
};
filter f_mailinfo {
level(info .. emerg) and facility(mail);
};
filter f_uucpinfo {
level(info .. emerg) and facility(uucp);
};
filter f_emerg {
level(emerg);
};
filter f_to_console {
not (facility(authpriv)) and
((level(notice .. emerg) and facility(auth))
or (level(debug .. emerg) and facility(kern))
or (level(crit .. emerg) and facility(mail))
or level(err .. emerg));
};
filter f_to_root {
(level(debug .. emerg) and facility(auth))
or (level(notice .. emerg));
};
filter f_to_loghost {
(level(notice .. emerg) and
  not (facility(auth,authpriv,cron,ftp,kern,lpr,mail,user)))
or (level(info .. emerg) and facility(auth,daemon,syslog,user))
or (level(debug .. emerg) and facility(authpriv,kern));
};
filter f_prog_doas {
program("doas");
};

filter f_from_857 {
(host(192.168.2.252))
};

log { source(s_local); filter(f_notice);destination(d_messages);};
log { source(s_local); filter(f_kerndebug); destination(d_messages);};
log { source(s_local); filter(f_msginfo);   destination(d_messages);};
log { source(s_local); filter(f_authinfo);  destination(d_authlog); };
log { source(s_local); filter(f_authprivdebug); destination(d_secure);  };
log { source(s_local); filter(f_croninfo);  destination(d_cronlog); };
log { source(s_local); filter(f_daemoninfo);destination(d_daemon);  };
log { source(s_local); filter(f_ftpinfo);   destination(d_xferlog); };
log { source(s_local); filter(f_lprdebug);  destination(d_lpderrs); };
log { source(s_local); filter(f_mailinfo);  destination(d_maillog); };
#log { source(s_local); filter(f_uucpinfo); destination(d_uucplog); 

producing SHA256 & release(8)?

[James Hartley]

Before proposing a diff, I need clarification.

The release(8) manpage states:

"xenocara uses DESTDIR and RELEASEDIR as described above.
While they may be set to the values used to build the rest of the
system, be aware that the existing contents of DESTDIR will be
removed as part of the xenocara build (this is necessary for
release checklist processing)."

Building the system release collects the SHA256 values of each fileset in
(traditionally) /usr/rel/SHA256.  This can be seen in /usr/src/etc/Makefile
as:

cksum -a sha256 BUILDINFO INSTALL.`arch -ks` \
${ALL_KERNELS} ${MDEXT} ${MISETS} | sort > SHA256

Building xenocara's release will overwrite the existing /usr/rel/SHA256
with the
SHA256 values of its base installation filesets if the same value of
$RELEASEDIR is used.  This can be seen in /usr/xenocara/Makefile:

 cksum -a sha256 x*tgz > SHA256

While this is not a showstopper & can easily be worked around, it seems
there is a mismatch between what the code does & what the manpage
specifies.  Is the intent now that building the system & xenocara releases
be done in separate directories, or should redirection be changed to
appending in the code?

Thanks!

Re: Sleep, Thinkpad x250

[Mike Larkin]

On Tue, Jul 12, 2016 at 02:50:33PM -0400, Donald Allen wrote:
> I have a Thinkpad x250 running 5.9 stable, up-to-date. This system
> will not re-awaken from sleep mode. No response to the power button --
> it just continues to sit there slowly blinking and does not respond to
> pings. Power cycling is the only way I've found to recover. dmesg
> below. I believe this is one of the Broadwell cpus Ted Unangst
> mentions in his blog post on OpenBSD and laptops.
> 

Starting with the x240, you need to disable the TPM in the BIOS for
resume to work. This applies to other models in the same line as well 
(eg, t440, t450, etc).

Try that and see if it fixes things.

-ml

> OpenBSD 5.9-stable (GENERIC.MP) #0: Tue Jul  5 21:42:13 EDT 2016
> d...@igor.allen.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 3959959552 (3776MB)
> avail mem = 3835744256 (3658MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (65 entries)
> bios0: vendor LENOVO version "N10ET38W (1.17 )" date 08/20/2015
> bios0: LENOVO 20CMCTO1WW
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT
> SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI MSDM BATB FPDT UEFI
> acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpiec0 at acpi0
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz, 1995.70 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
> ,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
> DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FS
> GSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz, 1995.39 MHz
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
> ,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
> DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FS
> GSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 1, core 0, package 0
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz, 1995.39 MHz
> cpu2:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
> ,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
> DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FS
> GSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 1, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz, 1995.39 MHz
> cpu3:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
> ,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
> DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FS
> GSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 1, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
> acpimcfg0 at acpi0 addr 0xf800, bus 0-63
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (PEG_)
> acpiprt2 at acpi0: bus 2 (EXP1)
> acpiprt3 at acpi0: bus 3 (EXP2)
> acpiprt4 at acpi0: bus -1 (EXP3)
> acpicpu0 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33),
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33),
> C1(1000@1 mwait.1), PSS
> acpicpu2 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33),
> C1(1000@1 mwait.1), PSS
> acpicpu3 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33),
> C1(1000@1 mwait.1), PSS
> acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1
> acpipwrres1 at acpi0: NVP3, resource for PEG_
> acpipwrres2 at acpi0: NVP2, resource for PEG_
> acpitz0 at acpi0: critical temperature is 128 degC
> acpibtn0 at acpi0: LID_
> acpibtn1 at acpi0: SLPB
> acpibat0 at acpi0: BAT0 model 

Re: Sleep, Thinkpad x250

[Ville Valkonen]

Hiya,

AFAIK the video card is the problem. Exit X and try to suspend &
resume. Works for me, also running X250.

--
Regards,
Ville

On 12 July 2016 at 21:50, Donald Allen  wrote:
> I have a Thinkpad x250 running 5.9 stable, up-to-date. This system
> will not re-awaken from sleep mode. No response to the power button --
> it just continues to sit there slowly blinking and does not respond to
> pings. Power cycling is the only way I've found to recover. dmesg
> below. I believe this is one of the Broadwell cpus Ted Unangst
> mentions in his blog post on OpenBSD and laptops.
>
> OpenBSD 5.9-stable (GENERIC.MP) #0: Tue Jul  5 21:42:13 EDT 2016
> d...@igor.allen.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 3959959552 (3776MB)
> avail mem = 3835744256 (3658MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (65 entries)
> bios0: vendor LENOVO version "N10ET38W (1.17 )" date 08/20/2015
> bios0: LENOVO 20CMCTO1WW
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT
> SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI MSDM BATB FPDT UEFI
> acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpiec0 at acpi0
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz, 1995.70 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
> ,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
> DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FS
> GSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz, 1995.39 MHz
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
> ,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
> DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FS
> GSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 1, core 0, package 0
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz, 1995.39 MHz
> cpu2:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
> ,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
> DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FS
> GSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 1, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz, 1995.39 MHz
> cpu3:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
> H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
> ,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
> DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FS
> GSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 1, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
> acpimcfg0 at acpi0 addr 0xf800, bus 0-63
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (PEG_)
> acpiprt2 at acpi0: bus 2 (EXP1)
> acpiprt3 at acpi0: bus 3 (EXP2)
> acpiprt4 at acpi0: bus -1 (EXP3)
> acpicpu0 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33),
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33),
> C1(1000@1 mwait.1), PSS
> acpicpu2 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33),
> C1(1000@1 mwait.1), PSS
> acpicpu3 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33),
> C1(1000@1 mwait.1), PSS
> acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1
> acpipwrres1 at acpi0: NVP3, resource for PEG_
> acpipwrres2 at acpi0: NVP2, resource for PEG_
> acpitz0 at acpi0: critical temperature is 128 degC
> acpibtn0 at acpi0: LID_
> acpibtn1 at acpi0: SLPB
> acpibat0 at acpi0: BAT0 model "45N" serial 15023 type LiP oem "SONY"
> acpibat1 at acpi0: BAT1 

Sleep, Thinkpad x250

[Donald Allen]

I have a Thinkpad x250 running 5.9 stable, up-to-date. This system
will not re-awaken from sleep mode. No response to the power button --
it just continues to sit there slowly blinking and does not respond to
pings. Power cycling is the only way I've found to recover. dmesg
below. I believe this is one of the Broadwell cpus Ted Unangst
mentions in his blog post on OpenBSD and laptops.

OpenBSD 5.9-stable (GENERIC.MP) #0: Tue Jul  5 21:42:13 EDT 2016
d...@igor.allen.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3959959552 (3776MB)
avail mem = 3835744256 (3658MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (65 entries)
bios0: vendor LENOVO version "N10ET38W (1.17 )" date 08/20/2015
bios0: LENOVO 20CMCTO1WW
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT
SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI MSDM BATB FPDT UEFI
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz, 1995.70 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FS
GSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz, 1995.39 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FS
GSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz, 1995.39 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FS
GSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz, 1995.39 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FS
GSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
acpicpu0 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1
acpipwrres1 at acpi0: NVP3, resource for PEG_
acpipwrres2 at acpi0: NVP2, resource for PEG_
acpitz0 at acpi0: critical temperature is 128 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "45N" serial 15023 type LiP oem "SONY"
acpibat1 at acpi0: BAT1 model "45N1127" serial  3494 type LION oem "LGC"
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
cpu0: Enhanced SpeedStep 1995 MHz: speeds: 2101, 2100, 2000, 1900,
1800, 1600, 1500, 1400, 1300, 1200, 1100, 1000, 800, 700, 600, 500 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 5G Host" rev 0x09
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 5500" rev 

Re: Override NGROUPS_MAX

[Jeremie Courreges-Anglas]

Sébastien Morand  writes:

> On Tue, Jul 12, 2016 at 4:35 PM, Alexandre Ratchov  wrote:
>>
>> On Tue, Jul 12, 2016 at 04:11:07PM +, Sébastien Morand wrote:
>> > Hi everybody,
>> >
>> > I'm implementing a samba share on OpenBSD 5.9 and I'm getting in trouble
>> > because of the NGROUPS_MAX limitation to 16 groups per user. Is there
any
>> > way to increase this value?
>> >
>> > For instance recompiling kernel with /usr/src/sys/sys/syslimits.h
> modified
>> > (NGROUPS_MAX to 32 or 64)? Using yellowpage?
>> >
>> > The same computer is an nfs client and nfs server (looks like the
>> > limitation apply over there too).
>> >
>>
>> iirc, this a limitation of the network protocol itself
>
> In Linux, ngroups_lax is 65536. Looks like ok there. So no way to change
it?

No reasonable way.  If you really need more than 16, better use another
OS.

As the net/samba port maintainer I thought about bumping NGROUPS_MAX,
but this requires some non-trivial work that I don't plan to investigate
before 6.0.  And then it would not change anything about the NFS
protocol limitations (that can be worked around by using only CIFS).

--
jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: Overide NGROUPS_MAX

[Sébastien Morand]

On Tue, Jul 12, 2016 at 4:35 PM, Alexandre Ratchov  wrote:
>
> On Tue, Jul 12, 2016 at 04:11:07PM +, Sébastien Morand wrote:
> > Hi everybody,
> >
> > I'm implementing a samba share on OpenBSD 5.9 and I'm getting in trouble
> > because of the NGROUPS_MAX limitation to 16 groups per user. Is there any
> > way to increase this value?
> >
> > For instance recompiling kernel with /usr/src/sys/sys/syslimits.h
modified
> > (NGROUPS_MAX to 32 or 64)? Using yellowpage?
> >
> > The same computer is an nfs client and nfs server (looks like the
> > limitation apply over there too).
> >
>
> iirc, this a limitation of the network protocol itself

In Linux, ngroups_lax is 65536. Looks like ok there. So no way to change it?

Re: Overide NGROUPS_MAX

[Alexandre Ratchov]

On Tue, Jul 12, 2016 at 04:11:07PM +, Sébastien Morand wrote:
> Hi everybody,
> 
> I'm implementing a samba share on OpenBSD 5.9 and I'm getting in trouble
> because of the NGROUPS_MAX limitation to 16 groups per user. Is there any
> way to increase this value?
> 
> For instance recompiling kernel with /usr/src/sys/sys/syslimits.h modified
> (NGROUPS_MAX to 32 or 64)? Using yellowpage?
> 
> The same computer is an nfs client and nfs server (looks like the
> limitation apply over there too).
> 

iirc, this a limitation of the network protocol itself

Re: Overide NGROUPS_MAX

[Ted Unangst]

Sébastien Morand wrote:
> I'm implementing a samba share on OpenBSD 5.9 and I'm getting in trouble
> because of the NGROUPS_MAX limitation to 16 groups per user. Is there any
> way to increase this value?
> 
> For instance recompiling kernel with /usr/src/sys/sys/syslimits.h modified
> (NGROUPS_MAX to 32 or 64)? Using yellowpage?

That define is used all over in userland too. It is a bad idea to change it.

Re: ratble and rdomain support on dhcpd and openvpn

[Chris Cappuccio]

Difan Zhao [difan.z...@pason.com] wrote:
> Thanks Pierre! However the command does not work for me... Do I need to 
> upgrade my openbsd box? I am on 5.8 right now.
> 
> # rcctl set dhcpd rtable 200
> usage: rcctl [-df] action|get|getdef|ls|order|set
> [service | daemon [variable [arguments]] | daemons | lsarg]
> # rcctl get dhcpd
> dhcpd_class=daemon
> dhcpd_flags=vr1
> dhcpd_timeout=30
> dhcpd_user=root
> 
> If it works, does it mean that dhcpd will only operate on rtable 200? It will 
> be nice if it can run on both rtable 200 and the default rtable 0...
> 

I believe under -current, you'd just:

ln -s /etc/rc.d/dhcpd /etc/rc.d/dhcpd200

rcctl set dhcpd200 rtable 200
rcctl set dhcpd200 flags "-f /etc/dhcpd.conf.200"

and use dhcpd200 and /etc/dhcpd.conf.200 to start for rtable 200, use dhcpd and 
/etc/dhcpd.conf for rtable 0

Chris

Re: shm_mkstemp(3) without the file name

[Ted Unangst]

bytevolc...@safe-mail.net wrote:
> When I use ftruncate(2) to actually allocate the segment, the file is as 
> long as the segment that is allocated.
> 
> Even if the file is unlinked before ftruncate(2) is called, enough free 
> space in the /tmp *file system* is required for the shared memory segment.
> 
> Is using ftruncate(2) to lengthen the segment the right way to do it, or 
> is this yet another stupid limitation of POSIX shared memory?

ftruncate is really the only way to do it.

There's nothing special about shm_open. It's just open with a different name.
If you want the files on a different filesystem, you can use open.

Overide NGROUPS_MAX

[Sébastien Morand]

Hi everybody,

I'm implementing a samba share on OpenBSD 5.9 and I'm getting in trouble
because of the NGROUPS_MAX limitation to 16 groups per user. Is there any
way to increase this value?

For instance recompiling kernel with /usr/src/sys/sys/syslimits.h modified
(NGROUPS_MAX to 32 or 64)? Using yellowpage?

The same computer is an nfs client and nfs server (looks like the
limitation apply over there too).

Thanks by advance,
Sebastien

Re: ratble and rdomain support on dhcpd and openvpn

[Difan Zhao]

Thanks Pierre! However the command does not work for me... Do I need to upgrade 
my openbsd box? I am on 5.8 right now.

# rcctl set dhcpd rtable 200
usage: rcctl [-df] action|get|getdef|ls|order|set
[service | daemon [variable [arguments]] | daemons | lsarg]
# rcctl get dhcpd
dhcpd_class=daemon
dhcpd_flags=vr1
dhcpd_timeout=30
dhcpd_user=root

If it works, does it mean that dhcpd will only operate on rtable 200? It will 
be nice if it can run on both rtable 200 and the default rtable 0...

Thanks!
Difan

-Original Message-
From: petrus...@gmail.com [mailto:petrus...@gmail.com] On Behalf Of Pierre 
Emeriaud
Sent: Tuesday, July 12, 2016 12:53 AM
To: Difan Zhao 
Cc: misc@openbsd.org
Subject: Re: ratble and rdomain support on dhcpd and openvpn

2016-07-12 7:41 GMT+02:00 Difan Zhao :
>
> So I have been playing with rdomain and I am able to get dhcp and 
> openvpn working but with some hacking. I am seeking a proper way to do this.


rcctl(8) is the way to go:

# rcctl set dhcpd rtable 200

# rcctl get dhcpd
dhcpd_class=daemon
dhcpd_flags=
dhcpd_rtable=200
dhcpd_timeout=30
dhcpd_user=root


(thanks again aja, much appreciated)

Re: shm_mkstemp(3) without the file name

[Theo de Raadt]

> Is using ftruncate(2) to lengthen the segment the right way to do it, or 
> is this yet another stupid limitation of POSIX shared memory?

If you are getting the picture that the standards commitee cobbled
together a bunch of junk and expected a good outcome, you are well
on your way to being on the same page as us...

Re: shm_mkstemp(3) without the file name

[bytevolcano]

Ted Unangst wrote:

bytevolc...@safe-mail.net wrote:

Yes, it seems to create files with long names (that have nothing to do
with the template I provide) in the /tmp root.

If it doesn't respect the path or template, what is the point of having
this argument there in the first place, and what is the point of even
having a file on the file system?


The file is the backing for the memory. The path is so that you can refer to
the same object. There's no requirement that the path be the name of the file
in the filesystem, since you don't use normal file functions to talk to it.


When I use ftruncate(2) to actually allocate the segment, the file is as 
long as the segment that is allocated.


Even if the file is unlinked before ftruncate(2) is called, enough free 
space in the /tmp *file system* is required for the shared memory segment.


Is using ftruncate(2) to lengthen the segment the right way to do it, or 
is this yet another stupid limitation of POSIX shared memory?
I did give SysV shared memory segments a go, but work required for 
cleanup is even more insane when the program crashes!





I do not see any promises here. The only promise here is that the shared
memory object will be created atomically. I found it creates long-name
files with mode 0600. If the implementation promises these permissions
for shm_mkstemp(3), then fantastic; it should really be mentioned in the
man page though.


"This implementation forces the mode to be 0600"


Thanks for pointing that out; I saw that, but I got confused as it was 
in the paragraph describing shm_open(3).





There's still an issue of the stale files on the file system, should
there be a crash, interruption, signal, or something like that. Even
with close(2), the file remains until shm_unlink(3) is called.


That's not unique to shm functions. Everything creating files can do that.



Indeed, but I don't see a use case for having shared memory backed 
verbatim by a file, to the point where the amount of shared memory that 
can be allocated depends on how much free space left in the /tmp file 
system.


Say I want to allocate 2GB shared memory object, I cannot do so with 
ftruncate(2) because I only have 128MB left in /tmp.

Re: shm_mkstemp(3) without the file name

[Ted Unangst]

bytevolc...@safe-mail.net wrote:
> Yes, it seems to create files with long names (that have nothing to do 
> with the template I provide) in the /tmp root.
> 
> If it doesn't respect the path or template, what is the point of having 
> this argument there in the first place, and what is the point of even 
> having a file on the file system?

The file is the backing for the memory. The path is so that you can refer to
the same object. There's no requirement that the path be the name of the file
in the filesystem, since you don't use normal file functions to talk to it.

> I do not see any promises here. The only promise here is that the shared 
> memory object will be created atomically. I found it creates long-name 
> files with mode 0600. If the implementation promises these permissions 
> for shm_mkstemp(3), then fantastic; it should really be mentioned in the 
> man page though.

"This implementation forces the mode to be 0600"

> There's still an issue of the stale files on the file system, should 
> there be a crash, interruption, signal, or something like that. Even 
> with close(2), the file remains until shm_unlink(3) is called.

That's not unique to shm functions. Everything creating files can do that.

Re: making OpenBSD 5.9 live system on USB key

[Boudewijn Dijkstra]

Op Sat, 09 Jul 2016 16:16:45 +0200 schreef Matthias Apitz
:

El día Saturday, July 09, 2016 a las 02:44:39PM +0200, Peter N. M.
Hansteen escribió:


[...] I suspect that's the case with your touchpad as well.

[...]
Re/ the touchpad: the imt(4) man page says, it should have support.
Is there some method in OpenBSD to get verboseor even debug boot
messages and


-DIHIDEV_DEBUG


to verify that the imt(4) driver is in the kernel?


config(8), boot_config(8)
fgrep imt /usr/src/sys/arch/amd64/conf/GENERIC


I read
that OpenBSD does not have loadable kernel modules, true?


True.


--
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

Re: shm_mkstemp(3) without the file name

[bytevolcano]

Jeremie Courreges-Anglas wrote:

bytevolc...@safe-mail.net writes:


Hello,

I am writing a local server which requires the use of shared memory
objects. Essentially, other applications communicate to this server by
connecting to a UNIX domain socket within the file system.

Occasionally such an application may require a shared memory buffer to
share large quantities of information with the server. In doing this,
the server uses shm_mkstemp(3) to create the shared memory objects, and
then sends the file descriptor over the connection.

char snm[25] = "/tmp/megaserv/XX";


I doubt that our shm_open(3) implementation will respect the path you
provide here.


Yes, it seems to create files with long names (that have nothing to do 
with the template I provide) in the /tmp root.


If it doesn't respect the path or template, what is the point of having 
this argument there in the first place, and what is the point of even 
having a file on the file system?





int fd;

fd = shm_mkstemp(snm);

/* Error handling omitted for clarity. */
/* Potential race condition here */

shm_unlink(snm);

...

/* Send fd over connected socket. */

Whilst the setup I have works well, I see a potential race condition,
albeit a very small one, in the position indicated above; an external
process, malicious or otherwise, can connect to the object in between
the shm_mkstmp() and shm_unlink() calls.


Not if the permissions on the file prevent this.

  "This implementation forces the mode to be 0600 or 0400, and prohibits
  sharing between different UIDs."


Furthermore, there is a small possibility for a stale file to be present
in the file system, should there be a crash.


Why not trust the promise made by shm_mkstemp(3)?


" If a temporary shared memory object is desired, the shm_mkstemp() 
function should be preferred as it avoids several possible security 
holes that tend to appear in programs trying to create their own unique 
temporary names.  The template argument is a string with at least six 
trailing Xs as described in mkstemp(3)."


I do not see any promises here. The only promise here is that the shared 
memory object will be created atomically. I found it creates long-name 
files with mode 0600. If the implementation promises these permissions 
for shm_mkstemp(3), then fantastic; it should really be mentioned in the 
man page though.


But I suppose if the malicious process is running as the user, then it 
can wreak all kinds of other havoc on the system; no need to protect the 
shared memory buffers then.


There's still an issue of the stale files on the file system, should 
there be a crash, interruption, signal, or something like that. Even 
with close(2), the file remains until shm_unlink(3) is called.





Is there a way of creating these objects without having to actually
create a file in the file system, something like pipe() or socketpair()?

For example:

int shm_create(int flags);

That would basically eliminate the race condition, the possibility of
a stale object, and make shm_unlink() unnecessary in this case.

Any advice/suggestions?

Re: shm_mkstemp(3) without the file name

[Jeremie Courreges-Anglas]

bytevolc...@safe-mail.net writes:

> Hello,
>
> I am writing a local server which requires the use of shared memory
> objects. Essentially, other applications communicate to this server by
> connecting to a UNIX domain socket within the file system.
>
> Occasionally such an application may require a shared memory buffer to
> share large quantities of information with the server. In doing this,
> the server uses shm_mkstemp(3) to create the shared memory objects, and
> then sends the file descriptor over the connection.
>
>   char snm[25] = "/tmp/megaserv/XX";

I doubt that our shm_open(3) implementation will respect the path you
provide here.

>   int fd;
>
>   fd = shm_mkstemp(snm);
>
>   /* Error handling omitted for clarity. */
>   /* Potential race condition here */
>
>   shm_unlink(snm);
>
>   ...
>
>   /* Send fd over connected socket. */
>
> Whilst the setup I have works well, I see a potential race condition,
> albeit a very small one, in the position indicated above; an external
> process, malicious or otherwise, can connect to the object in between
> the shm_mkstmp() and shm_unlink() calls.

Not if the permissions on the file prevent this.

 "This implementation forces the mode to be 0600 or 0400, and prohibits
 sharing between different UIDs."

> Furthermore, there is a small possibility for a stale file to be present
> in the file system, should there be a crash.

Why not trust the promise made by shm_mkstemp(3)?

> Is there a way of creating these objects without having to actually
> create a file in the file system, something like pipe() or socketpair()?
>
> For example:
>
>   int shm_create(int flags);
>
> That would basically eliminate the race condition, the possibility of
> a stale object, and make shm_unlink() unnecessary in this case.
>
> Any advice/suggestions?
>

--
jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

shm_mkstemp(3) without the file name

[bytevolcano]

Hello,

I am writing a local server which requires the use of shared memory 
objects. Essentially, other applications communicate to this server by 
connecting to a UNIX domain socket within the file system.


Occasionally such an application may require a shared memory buffer to 
share large quantities of information with the server. In doing this, 
the server uses shm_mkstemp(3) to create the shared memory objects, and 
then sends the file descriptor over the connection.


char snm[25] = "/tmp/megaserv/XX";
int fd;

fd = shm_mkstemp(snm);

/* Error handling omitted for clarity. */
/* Potential race condition here */

shm_unlink(snm);

...

/* Send fd over connected socket. */

Whilst the setup I have works well, I see a potential race condition, 
albeit a very small one, in the position indicated above; an external 
process, malicious or otherwise, can connect to the object in between 
the shm_mkstmp() and shm_unlink() calls.


Furthermore, there is a small possibility for a stale file to be present 
in the file system, should there be a crash.


Is there a way of creating these objects without having to actually 
create a file in the file system, something like pipe() or socketpair()?


For example:

int shm_create(int flags);

That would basically eliminate the race condition, the possibility of a 
stale object, and make shm_unlink() unnecessary in this case.


Any advice/suggestions?

Re: ratble and rdomain support on dhcpd and openvpn

[Gregor Best]

Ahoy,

> [...]
> Same  for the  openVPN.  I use  privateinternetaccess  service. I  ran
> "openvpn US\ Seattle.ovpn" to start the vpn and that gives me the tun0
> with IP on it.  Then I have run the following to move  the tun0 to the
> rdomain200 manually.
> [...]
> However, when the  openvpn times out or reconnects, it  gives tun0 new
> IP  and puts  tun0 back  in the  default rdomain  (0?). So  I have  to
> manually do this all over again... So anyway to configure it, maybe by
> editing the ovpn file?
> [...]

OpenVPN has a mechanism that allows using a user supplied script to do
the device configuration instead of having OpenVPN do that by itself.
I use the following for my IPredator VPN:

# --- 8< --- SNIP --- 8< ---
script-security 2 # Allows OpenVPN to execute scripts
ifconfig-noexec
route-noexec
route-up /etc/openvpn/ipredator/up.sh
up /etc/openvpn/ipredator/up.sh
# --- 8< --- SNAP --- 8< ---

The script looks like this:
# --- 8< --- SNIP --- 8< ---
#!/bin/ksh
case "${script_type}" in
up)
/sbin/ifconfig "${dev}" "${ifconfig_local}" \
netmask "${ifconfig_netmask}" mtu "${tun_mtu}" rdomain 3
;;
route-up)
route -T3 add default ${route_vpn_gateway}
;;
*)
echo "Unknown script type ${script_type}" | logger -t up
;;
esac
# --- 8< --- SNAP --- 8< ---

-- 
Gregor

Re: ratble and rdomain support on dhcpd and openvpn

[Pierre Emeriaud]

2016-07-12 7:41 GMT+02:00 Difan Zhao :
>
> So I have been playing with rdomain and I am able to get dhcp and openvpn
> working but with some hacking. I am seeking a proper way to do this.


rcctl(8) is the way to go:

# rcctl set dhcpd rtable 200

# rcctl get dhcpd
dhcpd_class=daemon
dhcpd_flags=
dhcpd_rtable=200
dhcpd_timeout=30
dhcpd_user=root


(thanks again aja, much appreciated)