Configuring passwordless write access to a specific `/sys` path for gnome-shell-extension-ideapad

Help
21

I simply get

Failed to start Application launched by gnome-shell.

pam_unix(sudo:auth): auth could not identify password for [myuser]

pam_unix(sudo:auth): conversation failed

So I’m assuming its the sudoers rule that went wrong but if I verify the sudoers file, I can see that our rule has been written successfully

%wheel  ALL=(ALL:ALL)    NOPASSWD: /usr/bin/tee /sys/bus/platform/drivers/ideapad_acpi/VPC????\:??/conservation_mode

Which is what we see in the extension’s README so I’m not sure whats going on anymore, maybe I need SETENV?

22

Nah, this won’t work on NixOS. The error message indicates that the plugin is working fine, but your sudoers config doesn’t currently exempt that command from requiring a password.

Having actually looked at the sudoers man page, the command must point to the absolute path of the command actually running.

The sudoers man page does not specify what happens if the command is a symlink.

So, I see a couple of potential issues:

  • The gnome extension uses tee from $PATH, who knows which tee is in gnome’s $PATH, this might not come from coreutils-full.
  • sudo may not follow the symlink to its path in the nix store, and the resolved path might therefore actually be in /run/current-system.
  • sudo might fully follow the symlink, at which point coreutils-full in turn is probably a symlinkJoin type thing, and therefore the symlink doesn’t resolve to the absolute path you had earlier.
  • The tee you’re using might not come from coreutils-full at all anyway.

I’d suggest you do the following:

  1. Run sudo tee in your terminal.
    • If you don’t get a password prompt, it’s the first issue, and you need to figure out which tee gnome is getting.
    • Have fun if it’s this, I have no idea how to even begin figuring that out without brute forcing store paths.
  2. If you do get a password prompt, it’s one of the latter.
    • Start by using command -v to figure out where your tee binary is, and then recursively resolve symlinks and keep trying different versions. You can test if your config is working with sudo tee every time you switch.

If that still doesn’t resolve it, the answer is somewhere in the sudoers man page (or just use man sudoers).

1 Like
23

So, its the latter and upon stating the tee binary I get

$ stat /run/current-system/sw/bin/tee
  File: /run/current-system/sw/bin/tee -> /nix/store/v4q3154vdc83fxsal9syg9yppshdljyk-coreutils-full-9.8/bin/tee
  Size: 70        	Blocks: 8          IO Block: 4096   symbolic link
Device: 259,2	Inode: 7227122     Links: 6
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-12-02 18:33:27.000000000 +0530
Modify: 1970-01-01 05:30:01.000000000 +0530
Change: 2025-12-05 19:24:35.311362881 +0530
 Birth: 2025-12-02 18:33:27.941669738 +0530

Which shows me that we’re using coreutils-full and since I’m using ${pkgs.coreutils-full}as my placeholder I think it should’ve been working but it isn’t for some reason I can’t figure out

24

Right, this then comes down to my two theories; it depends on how sudo treats symlinks, which is undocumented. You need to try each path recursively.

Try all of these paths until you find the one that works:

  • /run/current-system/sw/bin/tee
  • /nix/store/v4q3154vdc83fxsal9syg9yppshdljyk-coreutils-full-9.8/bin/tee
  • /nix/store/v4q3154vdc83fxsal9syg9yppshdljyk-coreutils-full-9.8/bin/coreutils
25

/run/current-system/sw/bin/teeis the only one that works.

Working Code:

security.sudo.extraRules = [{
    groups = [ "wheel" ];
    commands = [{
      options = [ "NOPASSWD" ];
      command =
        "/run/current-system/sw/bin/tee /sys/bus/platform/drivers/ideapad_acpi/VPC????\\:??/conservation_mode";
    }];
  }];

Thank you everyone

1 Like