Closed MrKich closed 8 years ago
How is this useful? You are running lots of untrusted code and opening hole if AS_ROOT is set.
I agree with this PR. It's not wlc's responsibility to babysit users, and there are often legitimate reasons to run it as root or not care about the security implications (i.e. working in a throwaway VM or something).
What are these legimate reasons, give me some real life use cases so I can consider this?
If this was added the correct way to do it would be to simply make wlc either warn or do nothing when running as root, not to add any kind of mechanism to request it.
I like tools which attempt to run as they're told and any errors and warnings should come from actual attempts to access resources any such which fail. I dislike UID checks, such as in other tools like pacman which requires fakeroot
hacks.
Here's an example: I need to go from a fresh install of Arch to a working desktop ASAP to test something on a virtual machine. I don't care about the security of this machine, it's going to be destroyed in a few minutes anyway. The overhead of creating a user and setting things up for it is just an annoyance. (this scenario has happened to me when makepkg dropped support for being run as root, very annoying, especially because in that case I had to set up sudo and such)
Write software as if your users are smart enough to make their own informed decisions about it.
This is a tangent, but to be fair the [nobody
](https://en.wikipedia.org/wiki/Nobody%28username%29) user is available for this reason. (Although I do tend to agree with the sentiment.)_
Getting an interactive session as nobody requires some setup on most distros, though. You'd get the same amount of setup necessary to just create a new user.
Maybe just remove the root check if there is need for this. Env variable for this seems funny.
Agreed.
you can do what makepkg used to do (still is?) in arch, were you could run as root if you run with --as-root
@nicman23: Not since https://projects.archlinux.org/pacman.git/commit/?id=61ba5c961e (almost 2 years ago)
I've always disagreed with that change, it's pretty far removed from the arch way imo.
Maybe it should be included in the API itself so compositors can handle it differently? I'd prefer the --as-root
flag but let the compositors handle how that works.
This issue isn't about makepkg.
The proper solution here is to not have any root checking at all. Because this pull request adds unnecessary code/complication, it likely won't be merged.
Try removing the UID
checks instead, that would likely have more success.
Just thought that running from root could be useful.