- Joined
- Nov 10, 2024
Often those things are run on separate servers with most of them being virtual machines with the OS serving as glorified boot loader for whatever you are running.
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
This implies you are running your machines solely through the root account. At that point, you don't need sudo; you already have all permissions. Filesystem permissions help keep any old program/process from accessing or writing to important or private files. Without them, literally anyone with machine access could read things like your ssh server private keys, users could change each other's passwords at will, and there is no longer any concept of user vs superuser.1st the only thing that lack of sudo is stopping you from is fucking with other users and since it is not the 70s anymore basically all unix system even the server ones run are single user.
This is completely batshit. If it were that easy to get around sudo (i.e. needing root perms), that defeats the whole purpose of it. Such a trick would be a pretty severe vulnerability. The core principle of hierarchical permissions systems is you need root-level access to hook and abuse anything that could give you root-level access. So again, and correct me if I'm wrong, these methods must depend on not just user-error but superuser-error.2nd there are thousands of ways of elevating to root which you unless you are total schizo are not going to check against for example you can echo shell wrapper to bashrc and from that get root.
The "in case" bit involves more than simply you as the sysadmin fucking up. Suppose a program you're superfluously running as root gets exploited using some specially crafted payload and a hacker gets code execution as a result. The potential damage this can cause is way greater than it would be if you ran the program with basic user permissions. In fact, a number of programs will actively warn you and refuse to start if you run them as root for this very reason.The only scenario in which sudo will protect you is in case or running it on throwaway however at that point just run it in container.
Aside from this, it's even common for daemons managed by systemd on normal consumer workstations to run as their own user that has limited FS perms to somewhere likePretty typically on a multi-purpose server box, you have a user per process.
and sql user for the database, web user for the http server, etc.
/srv
.You seem like the kind of guy who'd ignore the "don't run out on the range" rule at shooting ranges because you autistically insist you're a pro at ducking out of the way.Often those things are run on separate servers with most of them being virtual machines with the OS serving as glorified boot loader for whatever you are running.
Read the source code.says so on fucking wikipedia
How are you not acquainted with semver?everybody thinks completely breaking all compatibility from 2.2.6 to 2.3.0 is a completely normal thing to do
Lol. Construct a formal argument if you want to make ridiculous claims like this.You have yet to present an actual issue, or adequately address any criticism.
I agree.I do not wish to further contribute to shitting up the thread with a pointless argument
No it doesn't at all. Your ssh private keys do have permissions <your_user> users rw ie if i can run anything as your user i can read them. Your private and important documents do have similar permissions and as such i can read them as well. My point was since all important things are under one user if i have access to that user i have access to every important file on that system.This implies you are running your machines solely through the root account. At that point, you don't need sudo; you already have all permissions. Filesystem permissions help keep any old program/process from accessing or writing to important or private files. Without them, literally anyone with machine access could read things like your ssh private keys, users could change each other's passwords at will, and there is no longer any concept of user vs superuser.
Exactly it is completely batshit in fact it is utter nonsense and would never work! Except it does because your bashrc is owned by your user and as such program - actor working on user behalf can do the same thing as you do with the only obstacle being passwords(and some session nonsense but that can be circumvented by well bashrc) however no one can read keys that you press! No such thing would never happen it is not like X allows all programs to read all user input on UNIX(other session management programs are not better even Wayland).This is completely batshit. If it were that easy to get around sudo (i.e. needing root perms), that defeats the whole purpose of it. Such a trick would be a pretty severe vulnerability. The core principle of hierarchical permissions systems is you need root-level access to hook and abuse anything that could give you root-level access. So again, and correct me if I'm wrong, these methods must depend on not just user-error but superuser-error.
You do not understand the reason why UNIX permissions exists. They do exists to keep users on the same system for fucking each other over and they do fine job at it however in current day in which all dekstop UNIXs and majority of server UNIXes run all important things on singular user they are basically useless. The only way to get proper security on UNIX is either through things like apparmor or selinux however those are painfull to setup and as such basicaly no distribution even RHEL have it on as default or extensive containerisation.The "in case" bit involves more than simply you as the sysadmin fucking up. Suppose a program you're superfluously running as root gets exploited using some specially crafted payload and a hacker gets code execution as a result. The potential damage this can cause is way greater than it would be if you ran the program with basic user permissions. In fact, a number of programs will actively warn you and refuse to start if you run them as root for this very reason.
Oh no i cannot fuck with the useless daemon that does nothing of value. It is not like all the valuable things are under one user.Aside from this, it's even common for daemons managed by systemd on normal consumer workstations to run as their own user that has limited FS perms to somewhere like/srv
.
apt seems to be mostly c++ with only a couple hundred lines of perl (probably some testing shit) in the sources, my badRead the source code.
how are you not acquainted with it? as far as i understand, it goes major.minor.patch and since you're supposed to never break compatibility between minor versions, a 2.2.6->2.3.0 upgrade should be completely transparent to anything that links to the libraryHow are you not acquainted with semver?
many servers have (example) the http server under a user named after the server. "users" in unix don't really correspond to actual users, and can be used for whatever. many package managers automatically set up users for daemons you install, and when init spawns them, they get changed into that userYou do not understand the reason why UNIX permissions exists. They do exists to keep users on the same system for fucking each other over and they do fine job at it however in current day in which all dekstop UNIXs and majority of server UNIXes run all important things on singular user they are basically useless.
you say it does nothing of value when you don't even really know what it actually doesOh no i cannot fuck with the useless daemon that does nothing of value. It is not like all the valuable things are under one user.
The original argument was about piping things into sudo bash vs downloading them and then running them. My argument was that it is equivalent and in fact it is. If you are doing that on developer machine or on server as user that is used for installing things(ie one that does have superuser access). Obviously you are right that using permission system as form of isolation if the user does't have superuser access is effective.many servers have (example) the http server under a user named after the server. "users" in unix don't really correspond to actual users, and can be used for whatever. many package managers automatically set up users for daemons you install, and when init spawns them, they get changed into that user
My argument wasn't that no one uses unix accounts for privilege isolation but that wast majority of servers do serve only one singular function as such malicious code running on behalf of user responsible for that function is equivalent to malicious code running on root as eitherways the server ceases to be of any immidate value.you say it does nothing of value when you don't even really know what it actually does
most dev machines indeed have 1 user for everything, but most servers (and many desktops) get an entire user for each system-wide daemon
you are completely wrong that nobody uses unix accounts for privilege isolation, and user accounts are not completely useless for privilege isolation
when you unpack a tarball it doesn't execute any undefined code (assuming your tar isn't full of bugs and you used it right)The original argument was about piping things into sudo bash vs downloading them and then running them. My argument was that it is equivalent and in fact it is. If you are doing that on developer machine or on server as user that is used for installing things(ie one that does have superuser access).
fairMy argument wasn't that no one uses unix accounts for privilege isolation but that wast majority of servers do serve only one singular function as such malicious code running on behalf of user responsible for that function is equivalent to malicious code running on root as eitherways the server ceases to be of any immidate value.
key servers aren't 100% eitherPreferably you would get pgp key from key-servers instead from https so it is not 100% performative.
I only exchange GPG keys in-person at "cuddle parties" after hacker conventions. The smell never really goes away but it's a small price to pay for security.key servers aren't 100% either
ideally you check several different places in several different ways from at least 2 devices on 2 internet connections
Because Python coders are close to Nose jS coders in their Lego code obsession. import is_oddView attachment 7122093
Why does every python program ever made have eleventy bajillion dependencies?
I hate semver is practice because people don't actually do this. They break compatibility at the minor level way too often. Sometimes they break it at the patch level too. It's got to the point that one of our managers assumes the pattern is MAJOR.MAJOR.MINOR when upgrading certain third party software.how are you not acquainted with it? as far as i understand, it goes major.minor.patch and since you're supposed to never break compatibility between minor versions, a 2.2.6->2.3.0 upgrade should be completely transparent to anything that links to the library
if a change you want to do breaks a single user of your library you will have to go from 2.3.9 to 3.0.0
if you think that's really harsh and restrictive, remember that you can leave in the deprecated interfaces and just wrap the modern ones for another year or two, because they aren't hurting anybody
words cannot explain how much i want to fedpost right nowI hate semver is practice because people don't actually do this. They break compatibility at the minor level way too often. Sometimes they break it at the patch level too. It's got to the point that one of our managers assumes the pattern is MAJOR.MAJOR.MINOR when upgrading certain third party software.
Did they highlight that in red themselves? Perhaps a sub-conscious awareness...Apropos to this discussion from last month, I found a particularly egregious example from Gitlab local install instructions:
Even if you don't care about security, there's environment variables and file ownership to consider. For example; If the script puts something underAnd since the way that unix is designed there is no real difference between sudo bash and bash you might as well pipe it into sudo bash.
$HOME
(which seems to be the purpose of many of these scripts) then running that script as root may be less than ideal. I would suggest that this is a consequence of language specific package managers and an obsession with "best practices" e.g. DRY, NIH, etc. Why write a short 11 line function yourself when you could just depend on someone else's version of that same function?Why does every python program ever made have eleventy bajillion dependencies?
lol they did. It's even red with my dark reader extension disabled.Did they highlight that in red themselves? Perhaps a sub-conscious awareness...
I do that about once a week. He (Jamie Zawinski) occasionally has something interesting or funny to say but he seems about ready to have a stroke with his level of Musk Derangement Syndrome these days. That and his continued begging for money to run his San Fransisco SJW pizza club are making me consider once again starting a thread on him in PG.Every so often I pop into the most recent posts to watch him moo and ree about various things
thanks for the virus, very cooli want to see if this works on kf and i dont know where to put this
View attachment 7135012
what is even the point of this posti want to see if this works on kf and i dont know where to put this
The WebM format has been an ongoing disaster for the internet since the invention of Facebook. You cannot hate Google enough.i want to see if this works on kf and i dont know where to put this
View attachment 7135012
what are people complaining about thoughThe WebM format has been an ongoing disaster for the internet since the invention of Facebook. You cannot hate Google enough.