On Sun, Feb 21, 2021 at 1:38 PM Stuart Henderson wrote:
> I don't honestly think it's worth going to the trouble of disabling.
> Look at the other software you run which isn't enabled in OpenBSD by
> default - that's where your attack surface is ;)
Also look at your hardware, and look at the docu
Thanks Stuart, appreciate your time on this, and explanation of
the sndiod design
it was a case of I dont understand, dont use so I just disable.
and then I proceeded to ask out of turn shouldn't everyone else disable because
I dont understand or use it my self :/
Re attack surface / risk of ot
On 2021-02-21, Tom Smyth wrote:
> my thinking is by having the service off by default would reduce the
> default attack surface of the OS ?
The attack surface is tiny.
sndiod has a pair of processes each run as their own dedicated uid, one
in a chroot jail containing no files and pledged to not
If you are planning to deploy many systems in the near future and your
deployment script is very invovled then you might want to consider
building your own release and using that to install instead.
This way you don't need to append your deployment script to either
/install.site or /etc/rc.firstti
Hi folks,
thanks for everyone who replied on and off list,
I had not considered the console only user who uses audio also...
(I had not even considered this so pardon my ignorance folks,
and thanks to Sebastian, Abel, and David for replying on and off list
I guess Ill just add rcctl disable sndio
On Sun, Feb 21, 2021 at 8:39 AM Tom Smyth
wrote:
> Hi Sebastian
> I get users want to listen to audio but if the only hardware is a buzzer
> and the user is not running x what are the chances they are using audio on
> the console only ?
>
> I can keep running
> rcctl disable sndiod
> Post install
Hi Sebastian
I get users want to listen to audio but if the only hardware is a buzzer
and the user is not running x what are the chances they are using audio on
the console only ?
I can keep running
rcctl disable sndiod
Post install
I thought linking audio support on by default to x would make se
Tom Smyth(tom.sm...@wirelessconnect.eu) on 2021.02.21 04:08:48 +:
> Hello,
>
> I was wondering should sndiod (default) startup be determined based on
> whether or not
> it the install is a typical headless install (off) or an install for
> a user machine with running X
>
> is there a reason
Hello,
I was wondering should sndiod (default) startup be determined based on
whether or not
it the install is a typical headless install (off) or an install for
a user machine with running X
is there a reason why one would need to run this daemon by default?
my thinking is by having the servi
9 matches
Mail list logo
