[HN Gopher] Memory-safe sudo to become the default in Ubuntu
___________________________________________________________________
Memory-safe sudo to become the default in Ubuntu
Author : jnsgruk
Score : 182 points
Date : 2025-05-06 11:22 UTC (11 hours ago)
(HTM) web link (trifectatech.org)
(TXT) w3m dump (trifectatech.org)
| Rotundo wrote:
| Did sudo have memory problems? Did it ever fail because it didn't
| handle its memory correctly?
| stop50 wrote:
| Sudo had quite a few problems with security, partially because
| of this doas was developed for BSD. Some problems come from the
| huge amount of features(ldap, easter eggs, ...). sudo-rs
| reduces the problems by not implementing those features.
| XorNot wrote:
| Removing LDAP is a huge problem for the more important sudo
| deployments though: centralized management of permissions is
| kind of a vital function.
| Filligree wrote:
| Those people can keep using sudo; it's not going away. The
| rest of us get better security.
| fluidcruft wrote:
| Is it actually removing ldap or is it offloading to pam?
| JoshTriplett wrote:
| Debian is currently in the process of dropping the _direct_
| LDAP support in sudo, in favor of sssd. From sudo 's
| NEWS.Debian.gz:
|
| > In practice, there are few installations that use sudo-
| ldap. Most installations that use LDAP as a directory
| service and sudo have now opted for sssd, sssd-ldap and
| libsss-sudo.
|
| > The Debian sudo team recommends the use of libsss-sudo
| for new installations and the migration of existing
| installations from sudo-ldap to libsss-sudo and sssd.
| XorNot wrote:
| Ah that makes more sense.
| dec0dedab0de wrote:
| Could you clarify what you mean by more important sudo
| deployments?
| rnijveld wrote:
| The features we specifically don't support are those
| related to direct LDAP support within sudo, so things like
| loading a sudoers file directly from LDAP. Sudo-rs will use
| any user retrieved via NSS, such as when configured using
| SSSD to load LDAP users. And from the authentication side
| you can use whatever PAM supports, so anything like
| Kerberos etc, which again can be coupled with the same LDAP
| database.
| ch_123 wrote:
| > Some problems come from the huge amount of features(ldap,
| easter eggs, ...). sudo-rs reduces the problems by not
| implementing those features.
|
| This makes me wonder:
|
| 1) Would a hypothetical "sudo-lite" with these features
| removed lead to better security without a rewrite?
|
| 2) If these features are useful in the real world, will a
| Rust rewrite of sudo inevitably gain these features over time
| and end up with similar problems?
| throw0101a wrote:
| > _1) Would a hypothetical "sudo-lite" with these features
| removed lead to better security without a rewrite?_
|
| OpenBSD did this with their _doas_ utility:
|
| * https://en.wikipedia.org/wiki/Doas
| Dylan16807 wrote:
| "without a rewrite" means cutting down the existing code.
| A completely different program goes into the same
| category as "rewrite".
| 0cf8612b2e1e wrote:
| doas is 500 lines of C. Two orders is magnitude less than
| sudo yet still covers the core functionality. Sure you
| could grandfather"s axe your way into the final product,
| but difficult to see how a a hypothetical code base 1% of
| the original counted as anything but a rewrite.
| Dylan16807 wrote:
| Your phrasing sounds like you disagree with me, but
| you're saying the same thing, right? That doas is _not_
| an example of "without a rewrite".
| literalAardvark wrote:
| It can't end up with similar problems, due to the memory
| safety guarantee.
|
| That's not to say that it won't create other ones.
| ch_123 wrote:
| There are many types of security problems beyond memory
| safety issues.
| steveklabnik wrote:
| 2. While a feature may be useful, the question is how
| useful, and to how many people. sudo-rs is removing
| features that aren't used very much, if at all, and doesn't
| plan to add them, to combat this. Those users can still use
| the original sudo.
| mrweasel wrote:
| Ubuntu moving to a memory safe sudo implementation isn't
| actually that concerning to me. It's a good idea to have a
| smaller, safer sudo alternative as the default, as OpenBSD
| does with doas. Users can install sudo if they need it. My
| problem is that it needs to specifically be called something
| else than sudo. Again OpenBSD has doas, which to the users
| clearly isn't sudo, so users don't expect it to behave as
| sudo or configure as sudo.
|
| By all means, write a better, safer, smaller, more secure
| version of sudo, but don't have command be sudo or sudo-rs,
| name it something else.
| mid-kid wrote:
| There's been cases[1], of particular note, the unescape
| overflow one[2]. This one scathed the reputation of sudo enough
| to get people pushing for alternatives such as doas. The track
| record of vulnerabilities in general leaves a bit to be
| desired, even outside of memory vulns.
|
| [1]: https://www.sudo.ws/security/advisories/
|
| [2]: https://www.sudo.ws/security/advisories/unescape_overflow/
| Maxatar wrote:
| Yes it has:
|
| https://nvd.nist.gov/vuln/detail/cve-2021-3156
| ndegruchy wrote:
| Seems like the trifecta group is /just/ about migrating tools to
| rust? Am I understanding that right?
|
| I don't have a problem with it, specifically. Seems odd that they
| don't advertise it, though.
| john-h-k wrote:
| The other big thing iirc is they're all MIT licensed rather
| than GPL(et variants) licensed
| ndiddy wrote:
| Sudo is permissively licensed.
| https://www.sudo.ws/about/license/
| john-h-k wrote:
| Ah, interesting to know. I guess it is only the coreutils
| stuff where that is a concern
| kokada wrote:
| I am not sure if memory-safety is the biggest issue in sudo
| design. I find the fact that it is a setuid binary a much bigger
| issue because a bug can possible result in privilege escalation.
|
| I found an alternative implementation that doesn't rely in being
| a setuid binary like systemd-run0 much more interesting from a
| security perspective, but I am no security expert.
| Retr0id wrote:
| A bug in a daemon-based sudo alternative would surely also
| result in privilege escalation?
|
| I think the main benefit of eliminating setuid binaries is that
| you can forbid them system-wide (e.g. via mount flags), as a
| hardening measure.
| JoshTriplett wrote:
| There's value in always starting processes from a known-
| secure environment rather than attempting to transform a
| user's arbitrary environment into a secure one.
| Retr0id wrote:
| True, CVE-2021-4034 comes to mind as a recent example
| (exploiting zero-length argv)
| hedora wrote:
| How is that any different than a daemon that has a parser
| error in its message handler, except that the daemon
| could be misconfigured to listen on a network socket?
|
| The original unix process abstraction was extremely
| simple; the entire spec is a few pages.
|
| The problem is that Linux keeps adding more and more
| levels of Rube Goldberg machine to its security model, so
| now literally no one understands how a default minimal
| install of, say, Ubuntu works.
|
| Adding a magic daemon that runs stuff as root to this
| pile of complexity probably won't help. Ripping out
| almost all the cruft that's accumulated over the years,
| and adding back something sane (maybe BSD jails) would
| work a lot better.
| Dylan16807 wrote:
| > How is that any different than a daemon that has a
| parser error in its message handler
|
| The non-daemon has to parse just as much _in addition_ to
| making itself secure. Actually it needs to parse more
| things in more complex ways.
| hedora wrote:
| Assuming static linkage (which sudo has to assume),
| there's really not much to parse. It should just be
| dealing with a null-delimited list (argv) and the
| caller's environment variables (which it just needs to
| ignore and clear by default).
|
| Here's a simple implementation:
| https://github.com/TheMilkies/rut/blob/main/rut.c
|
| (Though it doesn't clear the environment unless I'm
| missing something - they should probably replace the call
| to execvp with one to execvpe, and add a null pointer to
| the end of the argument list).
|
| The problem of setting up root's environment and parsing
| the command line is left to the shell in both solutions
| (the thing I linked doesn't indirect through a root login
| shell).
|
| There's also the config file, but that's the same for
| both.
|
| Similarly, the system could be running some SEL
| derivative or be using a capability system that causes
| non-standard behavior from system calls, but the daemon
| has the same problem.
| kokada wrote:
| I think this post explains why much better than I can:
| https://mastodon.social/@pid_eins/112353324518585654.
|
| So yes, I am not saying that privilege escalation bugs are
| impossible if you have a different architecture, but like
| Lennart argues is that it makes them much more difficult to
| happen, especially because creating a proper setuid is
| difficult. Also there is a bunch of things that makes sudo
| especially tricky to implement correctly.
| MajesticHobo2 wrote:
| Right, but now the vector for privilege escalation will have to
| be a logic bug in memory-safe sudo instead of either a memory
| corruption (see CVE-2021-3156) or a logic bug. It's hard not to
| see this as a major improvement.
| charcircuit wrote:
| Being a setuid binary means that sudo also suffers from
| attacks where an attacker runs `sudo ./malware` and then
| convinces the user to authenticate. Depending on how sudo
| authenticates phishing attacks or password reuse from another
| breach can be used to escalate privileges.
| jvanderbot wrote:
| Those will also have to be fixed/considered, but do not
| detract from the contribution of removing memory safety
| bugs which may enable exploits.
| charcircuit wrote:
| This is a case of doubling down on bad design. To me it's
| wasted effort preventing theoretical bugs in niche
| setups.
| a_t48 wrote:
| Even with a new, perfect paradigm, there would be
| billions of systems running sudo for years.
| jvanderbot wrote:
| I think the opposing view is that moving away from sudo
| is substantially more effort and would break basically
| everything to accomplish "the same" thing as robustifying
| sudo (for some very loose definition of "same")
| charcircuit wrote:
| Yes, it's more effort, but it's not close to being the
| same.
| pixl97 wrote:
| I mean moving from IPv4 to IPv6 is more effort, but it's
| not close to being the same...
|
| And it's also why it mostly has not happened for most
| people.
| im3w1l wrote:
| I don't think you can realistically enforce a security
| boundary between root, and a user account that occasionally
| elevates.
|
| You can enforce a boundary between root and an account that
| never elevates though. And as far as I understand hardening
| sudo helps with that.
| charcircuit wrote:
| >I don't think you can realistically enforce a security
| boundary between root, and a user account that
| occasionally elevates.
|
| So stop doing that!
| z3t4 wrote:
| What should you do instead?
| charcircuit wrote:
| Design the system so that you do not need users to
| escalate to root. Find each use case where a user may
| want to use sudo and then come up with an alternate way
| to accomplish that action from a regular account.
| lupusreal wrote:
| We have that, it's called android.
|
| Anybody who finds themselves using sudo is already well
| off the beaten path, by their own choice. There's nothing
| wrong with that.
| charcircuit wrote:
| Doing system updates is not off the beaten path.
| onli wrote:
| That would just elevate each regular account to be a root
| account. There is no other way to make things like
| modifying files directly under / possible, or to change
| system configurations. You can lock everything down
| instead, then you have Android, but then you have
| certainly not enabled everything a user can do with sudo.
| charcircuit wrote:
| >There is no other way to make things like modifying
| files directly under / possible
|
| It doesn't need to be possible.
|
| >change system configurations
|
| You can have an settings app to configure the system.
|
| >then you have Android
|
| Which is much farther ahead than Ubuntu on security.
| Ubuntu needs to play catch up.
|
| >but then you have certainly not enabled everything a
| user can do with sudo.
|
| The goal is not to be able to do everything. The average
| user doesn't need to be able to do anything. Especially
| with their regular account.
| butlike wrote:
| > The average user doesn't need to be able to do
| anything.
| zahlman wrote:
| Currently, for any given action, the following
| possibilities are implemented:
|
| * The user may never perform the action (would require
| sudo, but the user doesn't have sudo rights)
|
| * The user may sometimes perform the action (i.e. only
| after authenticating with sudo)
|
| * The user may always perform the action (is always
| implicitly authenticated)
|
| "Being root" is just another name for the last option.
|
| What fourth alternative do you have in mind?
| charcircuit wrote:
| >"Being root" is just another name for the last option.
|
| No, it's not. Take for example ping. If we want users to
| be able to always be able to use ping does that mean they
| need to be root? No, it doesn't. A privileged part of the
| OS can handle doing the raw socket and the unpriviledged
| user can talk to that part of the OS.
|
| The key point is that some operations that require
| privileges are okay to expose to a user, but giving the
| user privileges for everything is dangerous.
| rurban wrote:
| Capabilities. Proper microkernels already do that
| theamk wrote:
| how do they solve sudo's problems though? Exchanging
| "sudo" with "require-root-capability" or "start-
| privileged-session" will still have many of the same
| logic problems.
|
| Unless you mean something like "capabilities are always
| inherited, and there is no way to increase them", which
| would mean that sudo-like scripts are impossible, and you
| need to start all-new session as root user for admin
| actions. Good news, it's already possible in linux - just
| don't install "sudo", and maybe set up SELinux to
| disallow all escalation. Turns out no one wants to do
| this though.
| msm_ wrote:
| Who are you shouting at?
|
| Going back to the topic of the discussion, making sudo
| more resilient prevents a whole class of possible bugs
| (see CVE-2021-3156). You may not like sudo, but it is
| very commonly used to manage access, prevent accidental
| errors, or improve accountability on Linux servers and
| workstations. It is not going away. Therefore, improving
| sudo is a worthwhile goal and a thing to be celebrated.
| charcircuit wrote:
| I'm not shouting.
|
| >sudo more resilient prevents a whole class of possible
| bugs
|
| Good, but this doesn't fix the easiest way to escalate
| privileges as an attacker through sudo. Memory safety
| doesn't help people who run "curl | sudo bash" to install
| a random program from the internet.
|
| >It is not going away.
|
| But if work is done it could become very niche and
| eventually stop getting new usage over time.
| theamk wrote:
| > help people who run "curl | sudo bash" to install a
| random program from the internet.
|
| I don't think you can help those people, unless you
| seriously lock down the machine to the level of iPhone.
| Neither Android nor Windows have "sudo" for example, and
| yet they can get malware just fine... all the difference
| is instead of the password, user clicks on confirm button
| a few times.
|
| I advice to (1) think about how you use sudo (2) think
| what would you replace it with and (3) think how the
| replacement can be abused by malware.
|
| Here is one example:
|
| (1) Today I used "sudo" to run docker: "sudo -Eg docker
| docker run..."
|
| (2) the sudo-less replacement would be to add myself to
| docker group, or switch to rootless docker
|
| (3) If I add myself to docker group, malware can
| trivially escalate by starting a privileged container. If
| I switch to the rootless docker, I am weakening security
| boundary between my primary user and the docker
| containers I run.
| encrypted_bird wrote:
| > I'm not shouting.
|
| In text format, all-caps or the use of an exclamation
| mark are often used to indicate shouting.
|
| So, it is not unreasonable for people to read your
| sentence as such.
| IshKebab wrote:
| Why not? The way Windows does it should work in theory I
| think?
|
| Maybe you can't realistically do it on _Linux_ , because
| Linux doesn't care about desktop security and doesn't
| have the kind of privileged GUI that you need.
| reissbaker wrote:
| The way Windows does it is users are prompted to elevate
| permissions, and can be tricked into clicking "Yes," just
| like users can be tricked into using sudo.
| IshKebab wrote:
| Well yeah you can't enforce any security boundary if your
| threat model includes "user might be tricked".
|
| It can't be enforced on Linux because `sudo` can be
| trivially MitM'd, but you can't do that on Windows
| because it's just a click.
| reissbaker wrote:
| But the entire threat model we were discussing was that
| the user might be tricked:
|
| _Being a setuid binary means that sudo also suffers from
| attacks where an attacker runs `sudo . /malware` and then
| convinces the user to authenticate_
|
| That's why the OP said that's not an enforceable security
| boundary. If the user is capable of attaining superuser
| privs, you can trick them, regardless of how attaining
| those privs is implemented.
| im3w1l wrote:
| Windows is a bit different I suppose. Many pieces come
| together to make it kinda work there.
|
| * Privileged gui to display and approve what will run as
| you mentioned. In Linux, non-privileged gui is used to
| request permission to do... something.
|
| * Executable verification. Let's say someone with user
| level permissions swaps out the program you wanted to run
| for a malicious one. The replacement would not pass
| certificate checks which would be revealed in the
| privileged gui. Maybe you could supply an old version
| with known vulnerabilities though idk?
|
| * _Kinda_ commandline parameters verification. In Linux-
| land you can pass parameters to the program those could
| be intercepted with user-level permissions. In Windows
| this would be displayed in the privileged gui. However!
| The parameters are only visible if you click "show more"
| which I would guess <1% of people actually do.
|
| As an example of the last point I tested making a
| shortcut to cmd.exe and used Run As Administrator. Then I
| changed the shortcut to C:\Windows\System32\cmd.exe /c
| calc and again did Run As Administrator. Opens calculator
| instead of command prompt with identical approval gui
| (except with show more).
| hulitu wrote:
| > Being a setuid binary means that sudo also suffers from
| attacks where an attacker runs `sudo ./malware` and then
| convinces the user to authenticate
|
| So does your OS.
| remram wrote:
| I don't see how this attack is related to the setuid
| binary. No matter what method you provide to the user to
| elevate their privileges, they can be tricked into doing
| it. If it was provided by a daemon, built into systemd, or
| anything else, the problem would be the same.
| charcircuit wrote:
| It's related because malicous code can use the setuid
| binary to elevate its privileges.
|
| >If it was provided by a daemon, built into systemd, or
| anything else
|
| Yes, this is also dangerous.
| remram wrote:
| So what's your recommendation? Removing the user?
| zahlman wrote:
| Do you have in mind a design that enables users to escalate
| privileges while preventing them from being tricked into
| escalating privileges?
| h4ck_th3_pl4n3t wrote:
| A major improvement would be to get rid of glibc altogether.
| As long as glibc is the default, the problems persist.
| IshKebab wrote:
| That is possible: https://github.com/sunfishcode/eyra
| johnisgood wrote:
| Rust version of sudo had lots of ridiculous logic bugs. I do
| not see the improvement.
| TrueDuality wrote:
| Do you have an example of the logic bugs you're referring to?
| johnisgood wrote:
| I am pretty sure it is around here somewhere:
| https://github.com/trifectatechfoundation/sudo-rs/issues.
|
| I apologize, I do not bookmark these issues, but maybe I
| should start doing that? In any case, you will find logic
| bugs which may raise the question "is it really worth the
| rewrite?".
| internetter wrote:
| You have the burden of proof to substantiate your
| accusations. Until then they're entirely unfounded.
| butlike wrote:
| Aren't full rewrites pretty much universally considered
| harmful?
| yjftsjthsd-h wrote:
| A more interesting link is
| https://github.com/trifectatechfoundation/sudo-
| rs/issues?q=l... IMO. Glancing down that list, a lot of
| them aren't what I would personally view as major
| problems (ex. "rustup is inappropriate for security
| critical software" - maybe it is, but that's not a
| specific exploitable bug), but I would suggest
| https://github.com/trifectatechfoundation/sudo-
| rs/issues/575 as a potentially interesting looking
| example.
|
| > I apologize, I do not bookmark these issues, but maybe
| I should start doing that?
|
| Yes. If you want to point out problems, it _really_ helps
| if you can point at specifics.
|
| > In any case, you will find logic bugs which may raise
| the question "is it really worth the rewrite?".
|
| There's a cost/benefit question, but note that the mere
| presence of some bugs doesn't make a rewrite worthless.
| dev_l1x_be wrote:
| doas is a much simpler (and therefore better) alternative.
| JoshTriplett wrote:
| doas is not a compatible drop-in replacement for existing
| users.
| hedora wrote:
| I wonder if there's one that hardcodes a simple policy like
| "members of the wheel group can run any command with a
| password, and a 5 minute timeout", but is also sudo command
| line compatible.
|
| That's what 99% of distros default to, and it's simple.
| dev_l1x_be wrote:
| I did not claim that.
|
| Here is my doas config: cat /etc/doas.conf
| permit nopass jane as root
|
| It be read and understood without prior knowledge.
|
| Sudo: #ALL ALL = (root) NOPASSWD: C_ZFS
|
| I have no idea what is going here, not sure what ALL means,
| why root is in (), etc.
| 778464636 wrote:
| Neither is sudo-rs. From TFA:
|
| > some features of the original sudo will not be implemented
| in sudo-rs if they serve only highly niche use cases
| badgersnake wrote:
| For my limited use case, alias sudo=doas seems to work fine.
| Foxboron wrote:
| doas is a really bad option on Linux.
|
| The Linux port has not been maintained for 3 years. Has
| unmerged rowhammer fixes and generally a yolo auth system best
| described as "dangerous". You are better off using a well
| maintained project, that includes the CVEs^Wwarts.
|
| It's a mistake to think that `doas` on Linux is the same as
| `doas` on BSD.
| asmodeuslucifer wrote:
| That's good to hear.
| bpierre wrote:
| How does sudo-rs compare to run0?
| https://news.ycombinator.com/item?id=40205714
| paulddraper wrote:
| A trivial Google search answers that. run0 requires systemd-
| type OS.
| ranger207 wrote:
| Given that Ubuntu uses systemd like the vast majority of
| Linux systems nowadays, how does sudo-rs differ from run0?
| fweimer wrote:
| You might not have a systemd instance inside a container,
| but you still might want to switch user IDs there.
| hedora wrote:
| sudo-rs doesn't gratuitously require a root privilege
| daemon that regularly ships filesystem destruction and
| remote unauthenticated arbitrary code execution bugs.
|
| If your bar is "I'll tolerate such crap", you may as well
| run your desktop session as root.
| zahlman wrote:
| If sudo does this, as you imply, why do Linux system
| still exist that are not part of a botnet?
| paulddraper wrote:
| Implication is that systemd does this, not sudo.
| paulddraper wrote:
| sudo-rs uses setuid.
|
| run0 does not (and instead relies on systemd).
|
| ---
|
| To answer your next question: setuid, while historic, is a
| bit weird, and is disabled in some environments, e.g.
| NoNewPrivileges.
| postepowanieadm wrote:
| No one is rewriting systemd in rust?
| steveklabnik wrote:
| I'm not aware of any serious project to do so, there's been
| some small projects, nothing on the scale of uutils or
| sudo-rs.
| remram wrote:
| This one is easy: run0 is not implemented in a memory-safe
| language, but in C. It is likely to be hit by exploitable
| memory-handling bugs, like the rest of systemd, as has happened
| multiple times before.
| Gabrys1 wrote:
| > Ubuntu is the most widely deployed Linux operating system
|
| Nitpicking, but I thought Android was the most widely deployed
| Linux OS around...
| pphysch wrote:
| Maybe "deployed" is the key word here. Android is treated like
| a fixture of mobile devices rather than a fungible Linux
| distro.
| dist-epoch wrote:
| That's the logic Oracle uses to say Java is the most widely
| deployed language in the world, because it runs on phone sim
| cards and credit cards
| ffsm8 wrote:
| Android uses the Linux Kernel, but iirc (correct me if I'm
| wrong), it doesn't come with the required application to make
| it Unix and hence is not the Linux operating system. That would
| mean it's only using the same kernel as the Linux operating
| system?
|
| Idk, just speculating to maybe get the thought process
| steveklabnik wrote:
| > it doesn't come with the required application to make it
| Unix and hence is not the Linux operating system.
|
| Linux is not a Unix https://en.wikipedia.org/wiki/Unix-like
| flexagoon wrote:
| > That would mean it's only using the same kernel as the
| Linux operating system?
|
| There's no "Linux operating system". Linux is the name of the
| kernel. Android is an operating system, GNU/Linux is, things
| like BusyBox/Linux are. They're all operating systems that
| use the Linux kernel.
| ffsm8 wrote:
| Uh, didn't I say exactly that? Gnu/Linux Is just
| collegially known as "Linux" and the operation system
| suffix made it clear what he was talking about. I didn't
| come up with the usage of the term, I was merely trying to
| interpret their words.
| passivegains wrote:
| there's competing specs, holy wars, etc. but POSIX is
| kind of like what you're describing. popular distros are
| usually mostly-but-not-completely compliant.
| yjftsjthsd-h wrote:
| There was also the
| https://en.wikipedia.org/wiki/Linux_Standard_Base , but
| unfortunately it wasn't particularly successful.
| matheusmoreira wrote:
| Linux is a perfectly good operating system. If you're
| motivated enough, you can boot Linux straight into your
| software without any other dependencies at all. Linux
| operates the system just fine all by itself.
|
| There's this weird definition of "operating system" which
| means "some sort of platform with a shell and little
| commands like cp, ls, etc.". That's just what POSIX tells
| people an operating system is, not the ultimate truth. It
| doesn't have to be that way.
| butlike wrote:
| You kinda blew my mind just now. I never considered an
| operating system as a collection of packages before
| (conceptually speaking).
| FpUser wrote:
| I was Ubuntu user until they've introduced snap and started
| forcing it down everybody's throat. No more Ubuntu for me.
| vgb2k18 wrote:
| For me it was their begging for money on install.
| butlike wrote:
| Would you prefer the Microsoft way of begging for money
| before install?
| thesuperbigfrog wrote:
| >> I was Ubuntu user until they've introduced snap and
| started forcing it down everybody's throat. No more Ubuntu
| for me.
|
| What issues did you have with snap packages?
|
| I am not aware of any problems with snap packages.
|
| They have some pretty nice features compared to traditional
| packages:
|
| https://snapcraft.io/docs/get-started#p-19156-connect-an-
| int...
|
| If snap packages have caused problems for you, what were the
| problems?
| Ygg2 wrote:
| Some would say that Android isn't Linux OS[1]. It runs Linux,
| in same way Linux runs Wine. As a (POSIX) compatibility layer.
|
| [1] because it doesn't abstract the hardware platform, doesn't
| multiplex hardware, nor protect software principals from each
| other https://www.youtube.com/watch?v=36myc8wQhLo&t=8m48s
| apexalpha wrote:
| You are correct but in this context Linux means GNU/Linux.
|
| Bit like how tomato is technically a fruit but everyone knows
| that in the context of a supermarket it's a vegtable
| pietro72ohboy wrote:
| Ironically, Ubuntu's efforts to replace its GNU components
| with non-GNU alternatives is very quickly going to turn it
| back into just Linux.
| zamalek wrote:
| I have been using sudo-rs for over a year. The only issue that
| I've had is running into `-E` being unsupported once every few
| months - which is arguably a good thing because I shouldn't be
| naughty and allow arbitrary envs to leak into a privileged
| session.
| xvilka wrote:
| Next they should adopt uutils[1] as coreutils, findutils,
| diffutils, etc alternative.
|
| [1] http://github.com/uutils/
| steveklabnik wrote:
| They are: https://jnsgr.uk/2025/03/carefully-but-purposefully-
| oxidisin...
| mfld wrote:
| Related discussion from 2 months ago:
| https://news.ycombinator.com/item?id=43403821
| bArray wrote:
| > This move is part of a broader effort by Canonical to improve
| the resilience and maintainability of core system components.
| Sudo-rs is developed by the Trifecta Tech Foundation (TTF), a
| nonprofit organization that creates secure, open source building
| blocks for infrastructure software.
|
| Ubuntu continuously updates itself without permission, killing
| apps and losing previous state. You have the Javascript based
| Gnome window manager that is always bugging out. The Ubuntu
| packages, drivers and kernel are laughably behind Debian and even
| further behind mainline. Ubuntu continues to morph into something
| I don't believe in.
|
| That all said, Rust is not a smoking gun for incorrect
| application logic. It could still happily incorrectly execute
| stuff with the wrong permissions or blow something up badly. I
| think it's also a bad idea to offer it as a drop-in replacement
| when clearly features are still missing since a long time [1].
|
| [1] https://github.com/trifectatechfoundation/sudo-
| rs/issues?pag...
| wkat4242 wrote:
| I think you mean a magic bullet instead of a smoking gun :)
| bArray wrote:
| I meant "smoking gun" from a cyber security perspective, i.e.
| the conclusion or the final part of the investigation. "magic
| bullet" would also work here too though.
| MaKey wrote:
| Evidence, particularly of a crime, that is difficult or
| impossible to dispute. [1]
|
| Even with your explanation I don't think it fits here.
|
| [1] https://en.m.wiktionary.org/wiki/smoking_gun
| nmstoker wrote:
| You seem to have inferred the wrong meaning of "smoking
| gun" and that's why your usage above doesn't make sense.
|
| There's no valid reason cyber security people would take a
| well known idiom and repurpose it as you imply, and a quick
| Google suggests they haven't done this.
| rzzzt wrote:
| Fish in a barrel!
| Spivak wrote:
| > Ubuntu continuously updates itself without permission,
| killing apps and losing previous state.
|
| What? Is this some snap thing because apt sure as hell doesn't
| do this without you configuring it explicitly.
| passivegains wrote:
| apt won't on its own, but if you're using the official images
| there's probably a service running that's calling it,
| probably for security patches etc.
|
| The bigger problem is upgrading packages deliberately but
| being surprised by the results. My team's current favorite is
| the upgrade process itself suddenly having new interactive
| prompts breaking our scripts.
| rlpb wrote:
| > My team's current favorite is the upgrade process itself
| suddenly having new interactive prompts breaking our
| scripts.
|
| This is how dpkg and apt have worked in Debian and Ubuntu
| pretty much since their inception. Look into debconf, dpkg
| and ucf configuration to learn how to integrate these with
| your automation. The mechanisms for this have existed for
| decades now and have not substantially changed in that
| time.
| yjftsjthsd-h wrote:
| I thought DEBIAN_FRONTEND=noninteractive was supposed to
| avoid that?
| bbarnett wrote:
| That and a couple of -o's, like conf old (not sure, on my
| phone)
| nottorp wrote:
| I have the hardware for a new home server waiting to be set up
| (as in, I don't need a new home server i'm just messing around,
| so once in a while i log in and configure one more service).
|
| I tried the latest Ubuntu and it seems to be targeted at either
| containers or desktops. Everything I wanted to set up
| networking wise was a pain for my little non standard
| configuration.
|
| Ended up wiping it and installing Debian instead.
|
| As for this Rust thing, first question that comes to my mind is
| what features are missing from this new godly impervious to
| hackers by default implementation.
| bayindirh wrote:
| When there's Debian, Ubuntu is moot for servers and personal
| use (for power users at least).
|
| One of my former colleagues used to install Ubuntu servers. I
| replace them with Debian when I get the chance. I was already
| blacklisted for Snap, so I can't re-blacklist them for going
| uutils and sudo-rs, and that's sad (as in Bryan Cantrell's
| famous talk).
| watermelon0 wrote:
| Worth mentioning that many packages on Ubuntu are only
| available via snap, which includes docker-cli, so they cannot
| be used inside containers.
| mustache_kimono wrote:
| > That all said, Rust is not a smoking gun for incorrect
| application logic. It could still happily incorrectly execute
| stuff with the wrong permissions or blow something up badly.
|
| This side steps the issue which is "Does Rust help you make
| software more correct?" No one is arguing that Rust is perfect.
| There are plenty of bugs in my Rust software. The question is
| only -- are we better off with Rust than the alternatives?
|
| > I think it's also a bad idea to offer it as a drop-in
| replacement when clearly features are still missing since a
| long time [1].
|
| Your example is the Github issue page?
|
| Look -- I agree that, say, uutils/coreutils missing locales may
| frustrate some users (although I almost never use them). But
| "close enough" is more the Unix way than we may care to
| realize. But especially in this instance, because sudo is not
| POSIX (unlike locales which are). A distro is free to choose
| any number of alternatives.
|
| Ubuntu wants to lay claim to "the Rust distribution" and it's
| hard to blame them when Linux wants to lay claim to "the Rust
| kernel".
| bbarnett wrote:
| _Linux wants to lay claim to "the Rust kernel"_
|
| Entirely untrue. It may happen, but there is zero consensus
| to port Linux to rust. Not even the tiniest bit.
| mustache_kimono wrote:
| > Entirely untrue. It may happen, but there is zero
| consensus to port Linux to rust. Not even the tiniest bit.
|
| ... But I did not say there was a consensus to port Linux
| to Rust? I'm sorry you misunderstood.
|
| Now, why would Linux want to lay claim to being 'the Rust
| kernel' and how is that different than Linux being
| rewritten in Rust? I believe that there are many reasons
| why Linus chose to give Rust for Linux a chance. I believe
| at least one of those reasons is mindshare. If Linux chose
| not to experiment with Rust drivers, then that mindshare
| might go somewhere else.
| rlpb wrote:
| > Ubuntu continuously updates itself without permission...
|
| It does default to installing security updates automatically.
| However, this is completely configurable.
|
| It isn't reasonable to have different default behaviour -
| otherwise the majority of users would be vulnerable from a
| security perspective.
|
| If you want different behaviour, just configure it as you wish.
|
| > The Ubuntu packages, drivers and kernel are laughably behind
| Debian and even further behind mainline.
|
| This just isn't a reasonable description of reality.
|
| Unless you're referring to an Ubuntu LTS, in which case, of
| course it is: _that 's the entire point of Ubuntu LTS_, and
| Ubuntu users have the choice of using the six monthly non-LTS
| releases if they want more up-to-date packages, which Debian
| users do not have.
| reissbaker wrote:
| _Ubuntu continuously updates itself without permission, killing
| apps and losing previous state_
|
| I've never seen this happen and I've run Ubuntu in production
| for years. Apt does not auto-update unless it's configured for
| unattended upgrades -- and both Debian and Ubuntu allow you to
| configure unattended upgrades in apt. And unattended upgrades
| via apt should not kill running user processes or cause data
| loss.
|
| _The Ubuntu packages, drivers, and kennel are laughably behind
| Debian._
|
| This is just plain wrong -- even for the steelman argument of
| Debian unstable or testing, which are not intended for general
| use. Debian unstable and testing are on kernel 6.12. Ubuntu
| 25.04 is on kernel 6.14.
|
| Debian stable, meanwhile, is on 6.1. Ubuntu has the _far_ more-
| recent kernel.
|
| I don't know what you mean by "drivers" -- there aren't
| separate drivers on Linux from the kernel; they're shipped in
| the kernel. Ubuntu's are also more recent than Debian, since
| the kernel version is more recent.
|
| With respect to packages, obviously I can't check every package
| version, but e.g. coreutils in Ubuntu are on 9.5, released in
| March 2024; systemd on Ubuntu is a version released this year
| (and until last month Debian unstable and Ubuntu were
| identical); gcc is identical; etc. While Ubuntu occasionally
| lags Debian _unstable_ , it's not by much.
|
| If you compare to actual Debian stable, it's not even close.
| Debian stable is ancient.
|
| And ultimately... _Why are you using Debian unstable_? It 's
| called "unstable" for a reason. It receives basically no
| testing. Even the "testing" version is more stable, and that's
| not intended to be stable at all and doesn't necessarily
| receive security updates. Ubuntu is less-stable than Debian
| stable, but far more up-to-date; Debian testing is less-stable
| than Ubuntu... And usually still not even as up-to-date. Debian
| unstable is basically untested; if you want that you'd be
| better served by a rolling release distro like Arch where the
| packages are going to be way more up-to-date anyway.
|
| The Debian wiki cautions against treating unstable or testing
| releases as general purpose, so I truly don't think even this
| steelman is viable. [1] In fact, they refuse to even call
| Debian unstable a "release" since there are no release
| practices associated with it and the code is effectively
| untested.
|
| Ubuntu is nowhere near my favorite Linux distro, but claiming
| it's more out of date than _Debian_ is just FUD.
|
| Debian is very very stable -- at least, _Debian stable_ is --
| and people love it for that. But the tradeoff is that
| everything in it is ancient. If you want something that 's like
| Debian, but more up-to-date but slightly less stable -- that's
| Ubuntu. If you want a rolling release, that's Arch. (And of
| course, there are even more-different distros like NixOS or
| ostree-based ones; there's the Red Hat universe of RHEL and the
| closer-to-bleeding-edge Fedora; etc etc.) Using Debian unstable
| is either a magnanimous act of sacrifice in order to help test
| future Debian versions, or it's self-harm.
|
| Personally if I wanted to use a Debian-derivative on the
| desktop, though, I'd probably use System76's PopOS, which is
| basically a cleaned-up Ubuntu with some nice GNOME extensions.
| I'm more curious in the future to try out ostree-based distros,
| though, like the various Fedora Atomic ones, since they have
| nice rollbacks without the user-facing complexity of NixOS.
|
| 1: https://wiki.debian.org/DebianUnstable
| rbanffy wrote:
| What are the implications of the license not being GPL?
| steveklabnik wrote:
| sudo is already (basically) MIT licensed
| https://www.sudo.ws/about/license/
| rbanffy wrote:
| Oh well. Completely forgot about that.
| johnklos wrote:
| "This move is part of a broader effort by Canonical to improve
| the resilience and maintainability of core system components."
|
| Somehow "maintainability" has never been something I'd ever
| associate with Ubuntu. Is it a reference to their source tree?
| That'd make a lot more sense than if they were referring to the
| OS itself.
| figomore wrote:
| sudo-rs is already default AerynOS (SerpentOS).
___________________________________________________________________
(page generated 2025-05-06 23:01 UTC)