Re: xscreensaver locking disabled
On Thu, Sep 20, 2018 at 4:41 PM Ken M wrote: > I am following -current and use openbox if it matters for my window > manager. > xscreensaver is started by openbox, anyway when I try to lock, well this > is what > I see: > > $ xscreensaver-command -lock > xscreensaver-command: locking not enabled. > If xscreensaver decides it can't do locking, then when started it should write to stderr why it thinks that. Does openbox capture the stderr of the processes that it starts to some file you can review? If not, then stop xscreensaver with xscreensaver-command -exit and then start xscreensaver against manually in a shell and see what it says. Philip Guenther
xscreensaver locking disabled
I am following -current and use openbox if it matters for my window manager. xscreensaver is started by openbox, anyway when I try to lock, well this is what I see: $ xscreensaver-command -lock xscreensaver-command: locking not enabled. >From what I understand form the xscreensaver document that could happen if xscreensaver was not running as me, however a ps aux confirms it is running as me, My only guess is perhaps when I hosed the permissions this is some artifact. Here is the contents of what is in /usr/local/bin. If you also run xscreensaver could you confirm if this looks right. -rwsr-xr-x1 root bin 274128 Sep 13 03:42 xscreensaver* -rwxr-xr-x1 root bin 26240 Sep 13 03:42 xscreensaver-command* -rwxr-xr-x1 root bin 228744 Sep 13 03:42 xscreensaver-demo* -rwxr-xr-x1 root bin 150976 Sep 13 03:42 xscreensaver-getimage* -rwxr-xr-x1 root bin 39478 Sep 13 03:42 xscreensaver-getimage-file* -rwxr-xr-x1 root bin4293 Sep 13 03:42 xscreensaver-getimage-video* -rwxr-xr-x1 root bin 26392 Sep 13 03:42 xscreensaver-gl-helper* -rwxr-xr-x1 root bin 26802 Sep 13 03:42 xscreensaver-text* Short of that not sure if anyone else is having a similar problem. I can share my openbox config and of course my dmesg but I am not sure that is relevant. Ken
Re: relayd as transparent proxy
my bad, I still don't have the real source IP in my logs (just the local ip address of my server). Any advice for a **real** transparent proxy ?
Re: relayd as transparent proxy
I think I found something working, I leave it here for others.
Any advice is still welcome.
By the way, I'm confused about the "transparent forward" directive in
relayd.conf. It doesn't seems to work at all and setting a transparent proxy is
not using this keyword.
/etc/relayd.conf :
http protocol "http" {
tcp { nodelay, sack, socket buffer 65536, backlog 100 }
include "/etc/relayd.proxy.conf"
pass
}
http protocol "https" {
tcp { nodelay, sack, socket buffer 65536, backlog 100 }
include "/etc/relayd.proxy.conf"
tls { \
cipher-server-preference,\
no tlsv1.0\
}
pass
}
relay "www" {
listen on 127.0.0.1 port 8080
protocol "http"
forward to destination
}
relay "wwwtls" {
listen on 127.0.0.1 port 8443 tls
protocol "https"
For tls, you need /etc/ssl/127.0.0.1.crt and /etc/ssl/private/127.0.0.1.key
files. Use ln -s to link with your certificate if necessary.
In /etc/httpd.conf, leave this :
listen on * port 80
listen on * tls port 443
hsts preload
tls {
certificate ...
key ...
}
And finally, in /etc/pf.conf :
pass in on egress proto tcp to port www divert-to 127.0.0.1 port 8080 \
flags S/SA modulate state
pass in on egress proto tcp to port https divert-to 127.0.0.1 port 8443
\
flags S/SA modulate state
pass out on egress proto tcp all modulate state divert-reply
This way, relayd is a transparent proxy, you can changes headers and keep the
original source IP (useful for logs).
regards.
groups new
0 C Slovenia P SI T Ljubljana F irregular O BSD User Group Slovenia I M b...@groups.io U https://bsdug.wordpress.com N *BSD
Re: Include all Perl inside httpd chroot, use mtree and pull out unused for security
On Thu, Sep 20, 2018 at 06:54:07PM +0300, Lars Noodén wrote: > On 9/20/18, Chris Bennett wrote: > > I started manually to include Perl files one at a time to learn how > > things work at home on -current. Then I copied everything in. > > But why risk security for unused Perl? > > httpd(8) supports fastcgi so you can run outside the chroot and > communicate via a socket. > See httpd.conf(5) That way you can keep the chroot lean. > > /Lars > Thanks, I see what I need to learn about sockets. I have reading some manual pages and looking online to do. This will be very good to learn. Chris Bennett `
Re: Include all Perl inside httpd chroot, use mtree and pull out unused for security
On 9/20/18, Chris Bennett wrote: > I started manually to include Perl files one at a time to learn how > things work at home on -current. Then I copied everything in. > But why risk security for unused Perl? httpd(8) supports fastcgi so you can run outside the chroot and communicate via a socket. See httpd.conf(5) That way you can keep the chroot lean. /Lars
Include all Perl inside httpd chroot, use mtree and pull out unused for security
I started manually to include Perl files one at a time to learn how things work at home on -current. Then I copied everything in. But why risk security for unused Perl? I would like to eliminate the unused files and then use mtree to watch and use that to inform me of any in particular that need replacement during updates or security breaches using mtree. What is the actual syntax for the mtree files in /etc/mtree? I use vim. Should I use sqlports-compact or pkg_mgr, neither of which have I used before when updating? Or use output from mtree when security is run for first time after updates? Thanks, Chris Bennett
Re: opening fifo locks process in D state
On 2018-09-20 09:13:42, Alexandre Ratchov wrote: > On Wed, Sep 19, 2018 at 11:32:40PM +0200, michal.lyszc...@bofc.pl wrote: > > Hello, > > > > I've stumbled upon a weird problem. Long story short, I try to open > > fifo two times, once O_WRONLY and once O_RDONLY, both in separate > > threads - but on process. Unfortunately both threads are locked in > > open() functions. > > > > I prepared very small program that reproduces this problem for me, > > please see attached file and note that there is no error handling > > for readability. > > > > !!! Also note, this program may get stuck in D state, > > and you won't be able to SIGKILL it. > > > > Anyone got any idea why is this happening? Is something wrong with > > my code? > > This is a kernel bug, no program may behave like this. > > > It works properly on netbsd, freebsd, aix, hpux and linux. > > > > I don't know what info exactly you might need, but here is uname, > > it's almost clean system, I didn't make much changes, and > > especially not in the core. > > > > # uname -a > > OpenBSD bbs-i686-builder-openbsd.kurwinet.pl 6.2 GENERIC#163 i386 > > This is a old OpenBSD version; I reproduced it on 6.3 but not > on -current (this doesn't mean the bug was fixed). I confirm, just upgraded my system to: OpenBSD 6.3 GENERIC#490 i386 and problem is the same. I found a workaround. When I change flags in both open() to O_RDWR, the problem goes away, it's not much but it's something. Should I post a bug report? I cannot find a way to check if that was already reported or not. -- Best Regards
Re: opening fifo locks process in D state
On Wed, Sep 19, 2018 at 11:32:40PM +0200, michal.lyszc...@bofc.pl wrote: > Hello, > > I've stumbled upon a weird problem. Long story short, I try to open > fifo two times, once O_WRONLY and once O_RDONLY, both in separate > threads - but on process. Unfortunately both threads are locked in > open() functions. > > I prepared very small program that reproduces this problem for me, > please see attached file and note that there is no error handling > for readability. > > !!! Also note, this program may get stuck in D state, > and you won't be able to SIGKILL it. > > Anyone got any idea why is this happening? Is something wrong with > my code? This is a kernel bug, no program may behave like this. > It works properly on netbsd, freebsd, aix, hpux and linux. > > I don't know what info exactly you might need, but here is uname, > it's almost clean system, I didn't make much changes, and > especially not in the core. > > # uname -a > OpenBSD bbs-i686-builder-openbsd.kurwinet.pl 6.2 GENERIC#163 i386 This is a old OpenBSD version; I reproduced it on 6.3 but not on -current (this doesn't mean the bug was fixed).
