Programming thread

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 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.

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.
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.

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.
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.

Pretty 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.
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.

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.
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.

Edit: add word to clarify.
 
Last edited:
says so on fucking wikipedia
Read the source code.
everybody thinks completely breaking all compatibility from 2.2.6 to 2.3.0 is a completely normal thing to do
How are you not acquainted with semver?
You have yet to present an actual issue, or adequately address any criticism.
Lol. Construct a formal argument if you want to make ridiculous claims like this.
I do not wish to further contribute to shitting up the thread with a pointless argument
I agree.
 
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.
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 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.
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).
If you want to convince yourself that it works write python3 into your bashrc once you open bash next time instead of opening bash it will open python. From that it is't hard to imagine a malicious wrapper around your shell.
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.
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.
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.
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.
 
Read the source code.
apt seems to be mostly c++ with only a couple hundred lines of perl (probably some testing shit) in the sources, my bad
however dpkg, the lower-level package manager that apt uses, seems to have a bit under 30,000 lines of perl in it
this is according to something i found in debian.org at the root file listings of these packages' source code

anyway if you think that's a bad example, go look at gnu guix, which is almost entirely written in scheme yet it seems to work with c libraries quite fine

you can write a package manager in any language because unpacking a tarball isn't exactly some magic language-specific process
telling the compiler to find libraries in /usr/share/whateverlang or telling it to find them in C:\Users\Nigger\Documents\mylanglibs is also not some special magic that takes the unique capabilities of your language, it usually takes the user pressing --, some letters, =, and a path in the build system invocation
How are you not acquainted with semver?
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

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.
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
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.
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
no matter what kind of potential holes they have, disregarding them is disregarding defense-in-depth principles
 
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
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.
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
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.
 
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).
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)
you can unpack it with privileges but to actually run the code you don't need those privileges, but with a curl|sudo bash you literally stream in a script that can do anything to your computer
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.
fair

there's still one thing that downloading tarballs is way better at than most curl|sudo bash incantations: gpg verification
when you curl|sudo bash you are trusting that the server is not compromised and the https is not compromised, and sometimes the server does actually get compromised or the ca gets fucked or something
i will admit that most gpg verifications when downloading from websites are purely performative, because you get the key over the same https server as the archive, but it's still an extra layer of defense that somebody can hopefully notice something wrong (guy who downloaded it 6 months ago and kept the key tries to get it again and it's using a different key for some reason)

i just feel like these magic install scripts are actual weak points and are probably best avoided
 
Preferably you would get pgp key from key-servers instead from https so it is not 100% performative.
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, and then use a secure communication method to ask your friend in a different country to do the same
and if it all matches you're good to go
depends on how much security you want
 
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
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.
 
View attachment 7122093
Why does every python program ever made have eleventy bajillion dependencies?
Because Python coders are close to Nose jS coders in their Lego code obsession. import is_odd
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
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.
 
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.
words cannot explain how much i want to fedpost right now
 
Apropos to this discussion from last month, I found a particularly egregious example from Gitlab local install instructions:
Did they highlight that in red themselves? Perhaps a sub-conscious awareness...

And 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.
Even if you don't care about security, there's environment variables and file ownership to consider. For example; If the script puts something under $HOME (which seems to be the purpose of many of these scripts) then running that script as root may be less than ideal.

Why does every python program ever made have eleventy bajillion dependencies?
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?

Somewhat ironic for a language which claims to be "batteries included" as one of it's selling points.
 
Every so often I pop into the most recent posts to watch him moo and ree about various things
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.
 
The WebM format has been an ongoing disaster for the internet since the invention of Facebook. You cannot hate Google enough.
what are people complaining about though
i guess there was that chromium crash bug but surely they've fixed that, right?
if so they are retarded
people: "google format le bad i hate google format"
also people: *use chromium even though it's trash*

also webm is just a subset of matroska so if you want to blame somebody blame matroska
i cannot believe how uninformed people here can be
 
  • Mad at the Internet
Reactions: geckogoy
Back