rc: virtual_oss: Create a loopback device in the default configuration #16

Manually merged

christos merged 1 commit from christos/loop into main 2026-05-21 17:39:32 +00:00 AGit

Conversation 8 Commits 1 Files changed 1 +1

christos commented 2026-04-17 10:09:50 +00:00

Member

Copy link

The loopback device allows us to record desktop sound by reading from
it, or even use it as an input device, for example during a call.

Sponsored by: The FreeBSD Foundation
MFC after: 1 week

The loopback device allows us to record desktop sound by reading from it, or even use it as an input device, for example during a call. Sponsored by: The FreeBSD Foundation MFC after: 1 week

christos added 1 commit 2026-04-17 10:09:51 +00:00

rc: virtual_oss: Create a loopback device in the default configuration ... caea20be3e

The loopback device allows us to record desktop sound by reading from
it, or even use it as an input device, for example during a call.

Sponsored by:	The FreeBSD Foundation
MFC after:	1 week

christos requested reviews from emaste, markj 2026-04-17 10:21:38 +00:00

markj commented 2026-04-20 18:05:15 +00:00

Member

Copy link

What are the default permissions of the device? Does it let an unprivileged application record all sound that gets written to /dev/dsp?

What are the default permissions of the device? Does it let an unprivileged application record all sound that gets written to /dev/dsp?

christos commented 2026-04-23 10:26:38 +00:00

Author

Member

Copy link

Devices are created with 0666, see voss_dsp_perm in usr.sbin/virtual_oss/virtual_oss/main.c. So unprivileged users can indeed "snoop" the audio getting written to /dev/dsp.

That being said, if we don't let unprivileged users access it, someone who wants to stream their desktop audio, say, during a video conference, or a live stream, has to run the browser or streaming program as root, for example.

What threat are you having in mind?

Devices are created with 0666, see `voss_dsp_perm` in `usr.sbin/virtual_oss/virtual_oss/main.c`. So unprivileged users can indeed "snoop" the audio getting written to /dev/dsp. That being said, if we don't let unprivileged users access it, someone who wants to stream their desktop audio, say, during a video conference, or a live stream, has to run the browser or streaming program as root, for example. What threat are you having in mind?

christos commented 2026-04-30 15:34:38 +00:00

Author

Member

Copy link

@christos wrote in #16 (comment):

Devices are created with 0666, see voss_dsp_perm in usr.sbin/virtual_oss/virtual_oss/main.c. So unprivileged users can indeed "snoop" the audio getting written to /dev/dsp.

That being said, if we don't let unprivileged users access it, someone who wants to stream their desktop audio, say, during a video conference, or a live stream, has to run the browser or streaming program as root, for example.

What threat are you having in mind?

Bump.

@christos wrote in https://ron-dev.freebsd.org/FreeBSD/src/pulls/16#issuecomment-223: > Devices are created with 0666, see `voss_dsp_perm` in `usr.sbin/virtual_oss/virtual_oss/main.c`. So unprivileged users can indeed "snoop" the audio getting written to /dev/dsp. > > That being said, if we don't let unprivileged users access it, someone who wants to stream their desktop audio, say, during a video conference, or a live stream, has to run the browser or streaming program as root, for example. > > What threat are you having in mind? Bump.

markj commented 2026-05-06 14:02:07 +00:00

Member

Copy link

@christos wrote in #16 (comment):

Devices are created with 0666, see voss_dsp_perm in usr.sbin/virtual_oss/virtual_oss/main.c. So unprivileged users can indeed "snoop" the audio getting written to /dev/dsp.

That being said, if we don't let unprivileged users access it, someone who wants to stream their desktop audio, say, during a video conference, or a live stream, has to run the browser or streaming program as root, for example.

What threat are you having in mind?

@christos wrote in #16 (comment):

Devices are created with 0666, see voss_dsp_perm in usr.sbin/virtual_oss/virtual_oss/main.c. So unprivileged users can indeed "snoop" the audio getting written to /dev/dsp.

That being said, if we don't let unprivileged users access it, someone who wants to stream their desktop audio, say, during a video conference, or a live stream, has to run the browser or streaming program as root, for example.

What threat are you having in mind?

Any unprivileged user, including "nobody" would be able to open the device and snoop audio. Better would be to require the user to belong to some special group, akin to "video", no?

@christos wrote in https://ron-dev.freebsd.org/FreeBSD/src/pulls/16#issuecomment-223: > Devices are created with 0666, see `voss_dsp_perm` in `usr.sbin/virtual_oss/virtual_oss/main.c`. So unprivileged users can indeed "snoop" the audio getting written to /dev/dsp. > > That being said, if we don't let unprivileged users access it, someone who wants to stream their desktop audio, say, during a video conference, or a live stream, has to run the browser or streaming program as root, for example. > > What threat are you having in mind? @christos wrote in https://ron-dev.freebsd.org/FreeBSD/src/pulls/16#issuecomment-223: > Devices are created with 0666, see `voss_dsp_perm` in `usr.sbin/virtual_oss/virtual_oss/main.c`. So unprivileged users can indeed "snoop" the audio getting written to /dev/dsp. > > That being said, if we don't let unprivileged users access it, someone who wants to stream their desktop audio, say, during a video conference, or a live stream, has to run the browser or streaming program as root, for example. > > What threat are you having in mind? Any unprivileged user, including "nobody" would be able to open the device and snoop audio. Better would be to require the user to belong to some special group, akin to "video", no?

christos commented 2026-05-06 15:47:41 +00:00

Author

Member

Copy link

@markj wrote in #16 (comment):

Any unprivileged user, including "nobody" would be able to open the device and snoop audio. Better would be to require the user to belong to some special group, akin to "video", no?

I like this idea. We could create an "audio" group, which the user will have to be part of in order to open any sound(4) or virtual_oss(8) devices. I'll submit a patch.

@markj wrote in https://ron-dev.freebsd.org/FreeBSD/src/pulls/16#issuecomment-329: > Any unprivileged user, including "nobody" would be able to open the device and snoop audio. Better would be to require the user to belong to some special group, akin to "video", no? I like this idea. We could create an "audio" group, which the user will have to be part of in order to open any sound(4) or virtual_oss(8) devices. I'll submit a patch.

christos commented 2026-05-06 16:23:47 +00:00

Author

Member

Copy link

#26

https://ron-dev.freebsd.org/FreeBSD/src/pulls/26

christos commented 2026-05-11 14:05:23 +00:00

Author

Member

Copy link

Bump.

Bump.

emaste approved these changes 2026-05-21 17:06:42 +00:00

christos force-pushed christos/loop from caea20be3e to 8532b4a436 2026-05-21 17:37:56 +00:00 Compare

gitadm referenced this pull request from a commit 2026-05-21 17:39:30 +00:00

rc: virtual_oss: Create a loopback device in the default configuration

christos manually merged commit 8532b4a436 into main 2026-05-21 17:39:32 +00:00

gitadm referenced this pull request from a commit 2026-05-28 09:40:14 +00:00

rc: virtual_oss: Create a loopback device in the default configuration

Sign in to join this conversation.

Reviewers

No reviewers

markj

emaste

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

3 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

FreeBSD/src!16

No description provided.