Allow finer-grained permissions when opening a device about evdev HOT 4 CLOSED

With the pull request above, the following beep program works with lower privileges:

use evdev::{Device, EventType, InputEvent, SoundCode};
use std::{fs::OpenOptions, thread, time};

const FILE: &str = "/dev/input/by-path/platform-pcspkr-event-spkr";

pub fn beep(hertz: u16) -> std::io::Result<()> {
    Device::try_from(OpenOptions::new().append(true).open(FILE)?)?.send_events(&[InputEvent::new(
        EventType::SOUND.0,
        SoundCode::SND_TONE.0,
        i32::from(hertz),
    )])
}

fn main() {
    beep(440).expect("could not beep");
    thread::sleep(time::Duration::from_millis(500));
    beep(880).expect("could not beep");
    thread::sleep(time::Duration::from_millis(500));
    beep(0).expect("could not beep");
}

Udev rules:

ACTION=="add", SUBSYSTEM=="input", ATTRS{name}=="PC Speaker", ENV{DEVNAME}!="", GROUP="beep", MODE="0620"

from evdev.

@conqp I know this is closed, but I was wondering what's the practical security difference between write and append, in this context?

from evdev.

Back in the day when I wrote beep-evdev, it did not work with write and the aforementioned udev rule. I haven't been working with beep-evdev and udev lately, so I don't know what precisely was the issue. Are you able to reproduce it?
Also with the append permission rather than write, a user will never be able to accidentally create the file if it does not exist in the first place, though they'd need write permission on the parent directory anyway. But better be safe than sorry.

from evdev.

@conqp no, I haven't had an issue, I just saw this and wondered what the practical security differences between append and write were.

from evdev.