hyprpm-sudo for enable/disable?

[degobbis]

I hope I have opened this in the right discussion.

I'm referring to this change:
#10211

It is understandable that not everyone should install, uninstall or update something in the system, so also with Hyprland plugins, but if it is installed by the administrator, a user should be able to decide for himself whether he wants to use a plugin or not.

That's why I think it should be possible to activate and deactivate plugins without sudo.
In a multi-user system, I cannot grant sudo rights to every user, and not every user wants to use every plugin.

But maybe I just overlooked a new option in the configuration that makes this possible.

What do you think?

[khagaroth]

This should be fine for most plugins, but there should be a way for an administrator to specify plugins that are mandatory and cannot be disabled.

[vaxerski]

hm. That's... reasonable, though I think it's quite an edge case...

The thing is, enabling a plugin is essentially loading code into your display server. Should that be something a user can decide about? Debatable

[vaxerski]

I've added the variable. You can now enable / disable bars with hyprctl keyword plugin:hyprbars:enabled false/true

[kenshin33]

Sorry if this seems like a hijacking. what was the issue to begin with? I mean what are we defending against here?
as anything I run can wreak havoc in my system (the bigest and most dandgerous of all is what we usually call a browser), what makes the hyprpm so special in this regard so much so that it needs sudo to protect my home ?!?!
I may seem ranty, I assure I'm not, I'm genuinely curious here!

[vaxerski]

in general, modifying code should be guarded with sudo. I agree that enable/disable might be a bit excessive, but that's just how we store the state.

Every app you run, the binary of it, is not modifiable by a regular user, and plugins are binaries.

[kenshin33]

Tecnically you own the copy you're running you can modify it at runtime (LD_* tricks comes to mind) of you can attack the thing that's doing the running the shell via it's init files.

that is to say a lot of binary executables live inside you home, Browser extentions (yes yes javascript, still very very dangerous, they have access to a lot information), any --insert your modern language (go, rust, python, java .... etc) name her--'s modules one ca download off the internet (Hell go had a very very nasty supply chain attack builtin), an and all random thing one can clone off some random git repo on the internet.

It seems to me if someone has write access to my $HOME, being able to modify the binary plugins of my compositor is the last of my concerns.
Again, I'm no expert here but If I thought about the above a nastier more expert than me could do X times worse, just trying to wrap my head around this change.

[vaxerski]

the compositor is a bit special as it can do a bit more than a regular app. Sure, it might be excessive, but it's not a problem. Allowing to locally enable/disable can be made in the future, but for now, I don't think it's a massive problem.