Linux device permissions: understand access modes

The short answer

On Linux, a webcam and its built-in microphone appear as device files, and ordinary file permissions decide which users can open them. Each device file has an owner, a group and three sets of access bits: read, write and execute, for the owner, the group and everyone else. On most current desktop distributions you usually don't need to change these. When you log in at the machine, the system adds an access control list (ACL) entry that gives your active session access to local cameras and sound devices.

One condition matters most for speech capture: the webcam's microphone is a separate audio device. It is handled by the sound subsystem, not the video subsystem. Having permission to use the camera does not mean you have permission to use its microphone, and the reverse is also true. Two more layers can block audio even when file permissions are correct:

• The sound server (PipeWire or PulseAudio), which is what most apps actually talk to.
• App sandboxes such as Flatpak or Snap, which have their own permission controls.

What the three access modes mean

• Read (r): lets a process read data. On a capture device, this is how audio samples or video frames come in.
• Write (w): lets a process write data. On a device file, capture software usually needs write access too, because it sends control and configuration commands to the device. In practice, apps generally need both read and write to capture.
• Execute (x): lets a program file run. On a directory, it lets you enter the directory and reach the files inside. It has no practical meaning for a device file.

Linux checks these sets in order. If you own the file, only the owner bits apply. If you are in the file's group, the group bits apply. Otherwise the others bits apply. ACL entries can grant extra access to specific users or groups on top of this basic scheme.

Linux permissions chart

Permissions are often written as octal digits, one each for owner, group and others. Each digit is a sum: read is 4, write is 2 and execute is 1.

Digit | Symbolic | Meaning

0 | --- | No access

1 | --x | Execute only

2 | -w- | Write only

3 | -wx | Write and execute

4 | r-- | Read only

5 | r-x | Read and execute

6 | rw- | Read and write

7 | rwx | Read, write and execute

Mode | Symbolic | Typical meaning

600 | rw------- | Only the owner can read and write

640 | rw-r----- | Owner reads and writes; group reads

644 | rw-r--r-- | Owner reads and writes; everyone reads

660 | rw-rw---- | Owner and group read and write; others have no access (common for device files)

666 | rw-rw-rw- | Anyone can read and write (not recommended for cameras or microphones)

755 | rwxr-xr-x | Owner has full access; everyone can read and run or enter

Where webcam video and audio devices live

• Video: webcams appear as video4linux devices, usually named video0, video1 and so on, under the /dev directory. One physical camera can create more than one node.
• Audio: the webcam microphone is handled by ALSA, the Linux kernel sound layer. Its nodes are under /dev/snd. Capture devices have names ending in c, such as pcmC1D0c, and each card also has a control node.
• Groups: these nodes are commonly owned by root with the group video or audio and mode 660. Group names and defaults vary by distribution.

How to check access to a webcam microphone

The commands below are standard on most distributions. Some come from optional packages: arecord is part of alsa-utils, getfacl is in the acl package, and wpctl or pactl depend on which sound server you use. The ls output shown is only an illustration of the format; your device numbers and details will differ.

# List capture devices the kernel has detected
arecord -l

# Show permissions on sound device nodes
ls -l /dev/snd/

# Example format (illustrative only):
# crw-rw----+ 1 root audio 116, 4 <date> pcmC1D0c

# Show ACL entries (a trailing + in ls output means an ACL exists)
getfacl /dev/snd/pcmC1D0c

# Show which groups your account belongs to
id

# See what the sound server exposes as inputs
wpctl status          # PipeWire
pactl list sources short   # PulseAudio or PipeWire-Pulse

To read the ls output: the leading c means a character device. The next nine characters are the owner, group and others permissions. A trailing + means an ACL applies. If getfacl lists your username with rw-, your session has access even if you aren't in the audio group.

Groups versus session ACLs

Older advice often says to add your user to the audio or video group. That works, but it grants access permanently, including from remote logins and when you aren't the active user at the machine. With systemd-logind and udev, devices tagged for session access get an ACL for whoever is logged in locally at that moment. The ACL is removed when that session becomes inactive. Some distribution documentation advises against adding desktop users to the audio group for this reason, and because it can interfere with this per-session handling. Group membership is still the usual approach on headless systems or for services that run without a login session.

Changing permissions safely

Running chmod directly on a file in /dev only lasts until the device is unplugged or the system restarts, because udev recreates device nodes each time. For a lasting change, write a udev rule. For privacy, avoid opening capture devices to all users with mode 666. Keep group-based access with a mode such as 660, or rely on session ACLs.

# Example udev rule (illustrative; adjust to your needs)
SUBSYSTEM=="video4linux", GROUP="video", MODE="0660"
SUBSYSTEM=="sound", GROUP="audio", MODE="0660"

What this means for capturing speech

• If the conferencing app shows no microphone at all, first check whether arecord -l lists the webcam's audio device. If it isn't listed, the problem is detection, not permissions.
• If the device is listed but the sound server shows no matching input, check the device node permissions and the ACL for your session.
• If the sound server shows the input but a sandboxed app can't use it, check that app's sandbox permissions for audio or microphone access.
• If several inputs are available, choose the webcam microphone by name in the app's audio input settings. Apps may default to a different input, such as a laptop's internal microphone.
• Permissions only control whether audio can be captured. They don't affect voice quality, gain or noise. Those depend on the hardware, the sound server settings and the app.

Data protection considerations

Any process running as a user with read and write access to a capture node can record from it. That's why limiting the others bits and relying on session-scoped access reduces exposure. A camera indicator light, where present, shows the video sensor's state; don't rely on it to tell you whether the microphone is in use. Sandbox permission controls and the sound server's list of active recording streams are more direct ways to see which applications are capturing audio.

Evidence gaps

No product-specific or distribution-specific evidence was supplied for this guide. It covers general, well-documented Linux behavior only. Exact group names, default modes, sandbox permission names and which sound server ships by default all vary by distribution and release. Check your own system with the commands above, and see your distribution's documentation for its specific defaults.