I wouldn't suggest giving those permissions to your user because it opens up the possibility of a denial of service. With those permissions, any program running as your user can spawn lots of realtime threads that can take over the scheduler and lock the system up. This was detailed in the rtkit announcement, and preventing it is the reason rtkit exists: http://lalists.stanford.edu/lad/2009/06/0191.html
Maybe realtime audio is not important to you, and that's fine. But it's never as simple as "delete these things and now I have a secure system", you may be trading off security elsewhere to get that. Please also note that pkexec is not required to use polkit. You can remove pkexec and still have a functioning polkit installation and still use all those other daemons too. For a really secure system you may want to remove all suid binaries anyway and only use polkit or SELinux or something.
Nothing fake about it? That is one of the actions that RealtimeKit allows clients to request:
$ pkaction --action-id org.freedesktop.RealtimeKit1.acquire-high-priority --verbose org.freedesktop.RealtimeKit1.acquire-high-priority:
description: Grant high priority scheduling to a user process
message: Authentication is required to grant an application high priority scheduling
vendor: Lennart Poettering
vendor_url:
icon:
implicit any: no
implicit inactive: yes
implicit active: yes
In the default configuration that will be granted to clients that are part of a local console session, but denied to clients that are not (e.g., batch jobs, SSH). That policy can be further customized by the OS vendor, organization, site, or local admin in quite a flexible way.
Or it could be because those libraries actually do something and users want them? I really don't get these complaints. Is the C library an "invasive weed" because C programs require an ABI compatible C library to run?
They are invasive if they somehow end up on your system even if you don't need them and didn't ask for it.
The C library is something that I actually need, unlike a GUI sudo prompt for.. audio? I don't even know what such a prompt looks like because I've never seen one.
I'm sorry, now I really don't understand. If these libraries shipped with your distro, you asked for them. If they were dependencies of a package you installed, you asked for them. It's bizarre to me that there are hundreds of Linux distros with every combination of packages you could possibly ask for and I still see this complaints. It's very likely you didn't see a prompt because your distro configured it to not require a password. If you want to configure it to require a password, the system lets you do that. This is just another choice you have.
No, I didn't ask for a fucking GUI sudo with xml and javascript and local privilege escalation to root. I asked my computer to do something as basic as play sound, something that worked for decades without GUI sudo. Developers said they want to use pulseaudio for that. Whatever, if it finally plays audio without breaking every week. I don't have time to vet every package in every distro, and I didn't know it depends on a GUI sudo.
> If these libraries shipped with your distro, you asked for them.
If a bomb ships with a package you ordered, you asked for it.
Or maybe not? Maybe I didn't ask for it but a bunch of devs decided that (quoting you) "the users all want" it and I wasn't there to keep tabs on them.
And now that I know better, yes, I am looking for alternative distros because the ones I've been using include too many things I didn't ask for.
>I asked my computer to do something as basic as play sound, something that worked for decades without GUI sudo
Sure, security also was not great for decades. I know what you mean you don't have time to vet packages, very few people have time to do that, that's usually why you'd trust a vendor to do it for you and not keep second guessing their decisions because they published and fixed a CVE.
>I am looking for alternative distros because the ones I've been using include too many things I didn't ask for.
That's great, I wish you luck. Just keep in mind, eventually if you find you want to put a security prompt on something for whatever reason (maybe you find yourself shipping something to a less technically inclined user), I expect you will circle back around to the same solutions. They're there for you to use them. At that point it becomes whether the frustration with XML and Javascript is worth rewriting it with a different configuration format and scripting language. Maybe you also want to take these tools written in C and rewrite it in Go or Rust or something, I don't know. I would not say it's worth it unless you have some really extreme requirements. This doesn't to have the most expressive DSL you can think of it, it just needs to encode some simple logic in a well-understood way.
> that's usually why you'd trust a vendor to do it for you and not keep second guessing their decisions because they published and fixed a CVE.
Yes, I'm inevitably putting some trust in vendors. Unfortunately I'm having a hard time finding vendors (especially Linux vendors) that I can trust to make decisions that I find sensible and more or less in line with my intended usage of the system.
I have some experience with OpenBSD (after using it for more than a decade on a server and a few years on a laptop), and I can say with reasonable confidence that they would have never allowed polkit to be a part of their system in the first place. Similar to how they eventually said no to kerberos and just purged it. Similar to how they've refused things like PAM. Similar to how audio kept working fine with sndio (a very simple library & daemon) while I constantly had to battle the overcomplicated audio subsystem and ever-churning daemons on Linux..
That's the kind of Linux vendor I would like: a vendor who's trying to build something simple, and not something that tries to be maximally flexible and "everything for everyone". A vendor who can make decisions and if needed, build their own thing that suits their goals instead of shipping the same things every other distro ships.
There certainly are hundreds of distros as you say, but most of them offer little more than a different coat of paint, and ship the same third-party packages with more or less the same dependencies as you would have on any other Linux distro. After you've installed the few things you need, it doesn't matter much whether the banner says Arch, Fedora, Ubuntu, or whatever (in fact I run all three right now).
Creating another group every time and asking the sysadmin to add you to the group when you want a new permission is not an appropriate solution for the desktop. It also isn't fine grained (what if you want to only grant permission to one audio device, then you'll need to create lots of audio groups and keep track of them all) and doesn't handle the case where you want to temporarily grant privileges to some device for just one session. There is more to it than just the issue with ssh, and it's not superfluous. There is a very good reason desktops all use it.
Even though the situation described is strange to the point of having never happened in history you would still need to ask an admin to write policy to implement your interesting audio permission scheme just the same as one would need to ask an admin to add a group or you know automate the process with a gui or integrate the change in groups into updating or software installation.
I am sure that somewhere having an actual programming language available vs list of what can and can't be run with or without a password would enable some additional power in terms of control of the system but I cannot for the life of me imagine a situation where it would be all that useful.
I agree it's not particularly useful for home users, I expect most would go with the defaults provided by their distro and leave it there. This is meant for corporate deployments where sysadmins might need to write more advanced policies.
What sysadmin are desktop users having to ask for permission to use their own hardware? Even in 2001, if you had a laptop, you had access to use all it's hardware. Why wouldn't you?
How many groups do you think there are? There's only so many classes of hardware, so there's only so many groups. About 8 in total. You add the user to all of them at once. It worked just fine before polkit arrived.
Why would you want to temporarily grant privileges to hardware once? Who is trying to prevent the user from using their own hardware?
I detailed this in another comment, the reason desktops use it is to get those macOS-style permission dialogs that pop up when you try to take some privileged action. I don't think any desktop distribution wants to ask users to open a terminal and type "sudo usermod" and then log out and log back in in order to do something like setting the clock or formatting a usb drive. I don't remember this working well at all before polkit arrived either, I remember when device hotplug in Linux was really broken for this reason (and a few others). It's not reasonable to ask desktop users to edit udev rules when plugging in a new device. If it worked well at all it was because you were doing things like having a lot of suid/sgid tools or just running GUI programs as root which is a terrible idea.
>Who is trying to prevent the user from using their own hardware?
I don't understand this question. The functionality here is equivalent to sudo, you type your password to authenticate a certain action. As the sysadmin you can configure some actions to always accept or always deny, if you want.
Yes, polkit does have some overlap with sudo. What it has over sudo is a real API, programs can use it to authenticate an IPC request for an action to a privileged daemon while that daemon is running.
Why isn't the audio device owned by the logged in user? udev could easily do that.
It'd be a problem if more than one user in logged in to the local console, in a multi head environment for example. But those are rare, and already have to solve the same problem for other console related devices such as mice and keyboard.
Sorry but if you keep falling back to the terminal to do things I would say you're not really using a desktop. What's the purpose of pointing this out? Yes, you can do whatever you want in Linux by opening the terminal and typing sudo. I understand the propensity of developers to like this because we spend all day in our xterm windows anyway but this is not the way anyone else expects a desktop to work.
Just to follow this discussion a bit further: If you have a task that /really/ needs elevated privileges you could turn it into a kernel module. That's great for you if you want to do that, but will you tell everyone else to develop kernel modules for every little thing? I don't think I would. I'm happy to give the muggles a better interface.
I have no "desktop" tasks that need elevated privileges. I only use a GUI because I want to run things like a browser and a media player. If I need elevated privileges it's always a one-off job, which means I need a commandline anyway.
There's a bunch of influential people that are bent on making "Linux desktop" be something that competes effectively with Windows and MacOS. Setting aside that I don't think those are particularly desirable objectives in the first place, I simply don't see it happening. Despite their deficiencies, Windows and MacOS work better than Linux desktops.
A lot of the Linux desktop effort seems to really be "Linux laptop" - Linux support for machines that are constantly moving from one hotspot to another, and constantly having storage and other devices plugged in and unplugged. That isn't my use-case. Most of my Linux machines are servers with no GUI. The one with a GUI doesn't travel, and gets something plugged into it maybe once a month.
I realise that my usage pattern isn't universal; I was just correcting the claim that "all desktops use it". You only need one counterexample to refute such a claim.
> There's a bunch of influential people that are bent on making "Linux desktop" be something that competes effectively with Windows and MacOS.
And not necessarily with the interests of Windows or MacOS end users, but more corporate interests.
I think a lot of Windows users for example were and would still be fine with a system that is effectively a single-user desktop. A permission prompt to prevent random apps from spying on you using your microphone and camera is probably a Good Idea for the average user but all this user policy business is just pointless; users themselves should always have access to their own devices anyway, just as they would on old Windows installs where the user was typically the only user and always administrator.
And yeah, I don't like that a few people get to define what exactly constitutes a desktop for everyone. Especially if under the guise of "this is what a modern desktop requires" they're free to turn the platform into a bloated, overcomplicated mess.. exactly the kind of thing I was happy to get away from when I left proprietary operating systems behind two decades ago.
I don't understand what you mean by a few people get to define it. This stuff is used by basically every desktop environment on Linux. You have to either use it or write something very similar to it if you want to have permission prompts that actually work. They all give the option to turn it off but they still have to support it for the average user you described. Unsurprisingly, the requirements for shipping a desktop are really not that different on Linux compared to other operating systems. The users all want the same things.
From what I have seen, the amount of users that want to go back to the Windows 95 style of security are an even fewer people. You can find distros that still ship a desktop from that era but they don't seem to be for much beyond novelty.
Why would I want permission prompts? Most systems are single-user systems; if you're logged in, you're the administrator, even if you haven't yet invoked your superpowers. Arguambly you should have to confirm if you want to do something dodgy; but if all you have to do is say "Yes, thanks for the warning", then you don't need any kits.
Really, I have difficulty imagining this group of Linux users who are constantly hot-laptoping, so that they need multi-user support sprinkled all over the OS. I can see that it's useful in a pair-programming environment, where you might have a lab or workstations with a standard config; but apart from that, how often does someone else log in to a desktop/laptop computer you normally use? Or one you own?
I don't think hotdesking and hotplugging are urgent consumer requirements. I don't think the people producing this stuff are aiming it at consumers.
> or write something very similar to it
Or use what was written before, if it matches your use-case. That worked, for many people. Still does for some.
Please don't speak for everyone. It's exactly this patronizing we-know-better-than-you attitude that makes users hate their corporate software vendors.
> From what I have seen, the amount of users that want to go back to the Windows 95 style of security are an even fewer people.
I knew someone would immediately reply with this straw man as soon as they saw mention of old Windows. I said user policies are pointless for a single-user desktop. It's irrelevant whether dave and samantha can access the audio device in john's session because dave and samantha don't exist on john's personal computer and he sure ain't running an ssh daemon for them.
>Please don't speak for everyone. It's exactly this patronizing we-know-better-than-you attitude that makes users hate their corporate software vendors.
I'm not speaking of corporations here, this is basically every current desktop environment that is shipping on Linux right now. They are all either using polkit or they use something very similar to it because the idea of it (user asks to perform an action, show a prompt) is very straightforward and pretty much universal for GUIs by now. Some of them may be business-oriented but some aren't. If this doesn't fit the definition of "everyone" using desktop Linux then who else are you considering? And just to clarify, I would say using sudo with a fine-grained config is roughly equivalent to polkit, although less convenient for GUI users because it doesn't have pluggable authentication agents.
>I knew someone would immediately reply with this straw man as soon as they saw mention of old Windows. I said user policies are pointless for a single-user desktop.
This itself is a strawman though. Polkit and sudo and such are not strictly about user policies although you can use them for that.
>If I need elevated privileges it's always a one-off job, which means I need a commandline anyway.
This is why polkit actions are the way they are, so you actually have a chance of being able to encode those one-off tasks into permissions for a GUI. It's not implemented for everything that requires root, and it probably won't ever be implemented for all of it but it's a lot better than it used to be. Part of it is improving because desktops like KDE made it easier to plug in new panels to the system settings, another part is that applications started using the higher level D-Bus APIs (like udisks2, timedated, networkmanager, etc) instead of trying to access the raw devices themselves.
>There's a bunch of influential people that are bent on making "Linux desktop" be something that competes effectively with Windows and MacOS. Setting aside that I don't think those are particularly desirable objectives in the first place, I simply don't see it happening. Despite their deficiencies, Windows and MacOS work better than Linux desktops.
I don't disagree with the last part here but, companies like Canonical exist and they get paid to ship this stuff. There are customers out there who want this, and they may very well be the ones paying some money or contributing maintenance towards keeping your browser and media player working on Linux. I don't know any overarching reason why these customers would deploy Linux instead of Windows, you would have to ask them.
>I realise that my usage pattern isn't universal; I was just correcting the claim that "all desktops use it". You only need one counterexample to refute such a claim.
Sorry but I don't think any usage of the terminal is a counterexample. That's just sidestepping the desktop, you could also do that from a VT with no GUI present.
> another part is that applications started using the higher level D-Bus APIs (like udisks2, timedated, networkmanager, etc)
Not the applications that I use! The machine in question doesn't have dbus or systemd. It only has one user. That layer of complexity is of zero value to me, but it's the very devil to get rid of it all.
> Sorry but I don't think any usage of the terminal is a counterexample.
If, on Windows, you have to perform a task for which there is no pre-made GUI app you can install, then you have to run-up powershell or cmd. My case is identical. I specifically referred to one-off tasks.
It's not my use of terminals that is the counterexample; it's the fact that I run a desktop without polkit (or anything-kit).
On Windows, if there has been value in putting those tasks in a GUI in the control panel, they will do it. It's the same deal.
Yes you can technically build a system without dbus or systemd or polkit or gettext or the C library or whatever it is you feel is superfluous. As you've found it is not actually difficult to do that, just tedious and impractical. You aren't gaining anything here by removing things. If you want equivalent functionality you're now tasked with building the equivalents, e.g. Android which is also a single user userspace for Linux without dbus or systemd, but has its own fairly complex set of high level services and IPC system.
> As you've found it is not actually difficult to do that, just tedious and impractical.
That is the opposite of what I have found; I find that it's "the very devil" to remove these components. And my finding is that the presence of these components is tedious and impractical, and that their absence makes my life better.
> You aren't gaining anything here by removing things.
That is condescending.
I've used machines with these services and I've used machines without. I find it's a gain to not have them. Who are you to tell me whether I do or don't gain anything?
FTR I don't have to build anything; there are alternatives, which I use. Unfortunately these new components are more-or-less rivetted-in, which makes it hard to remove them and replace them. Screws are better than rivets.
>given the "move fast, break things, wontfix" approach the systemd authors currently have with the project.
I don't understand where anyone is getting this impression from, that describes the opposite of my experience with systemd. The authors publish stability guarantees, and they have done so for several years: https://systemd.io/PORTABILITY_AND_STABILITY/
I love systemd both for it's actually functionality and the fact that it's almost like the flagship of a whole movement to make Linux more consistent and integrated and less of a pile o scripts.
But for some reason, the authors occasionally say something that feels completely out of place for the project. They fix important stuff eventually, but sometimes it gets confusing to watch them discuss it.
The "Invalid username runs a service as root" bug is a good example of something that they didn't seem to take seriously. But it's fixed now.
Also, PulseAudio. Pulse is good. It's not that great and was deployed before it's ready on some distros. The whole Pulse/Jack split that is only just now being fixed was annoying.
Some people might still judge Poettering based on 10yo bugs in Pulse rollout?
After a lot of recent events, I don't feel comfortable judging any open source project on the speed at which they fix bugs or the way they communicate about it. In open source there is no obligation for anyone to fix anything or communicate anything. To me it's a miracle when anything gets fixed at all. It feels like the community is still largely held together with duct tape and string.
Yeah, I just expect all software to be buggy. To be honest my main way of evaluating software is by Googling stuff like "X ate my data" or "X stopped working" and seeing how many major complaints people have, relatively to how many users there are.
I think the duct tape and string feeling comes from the obsession with smallness and modularity and people trying to make "Linux not be like windows".
Half the FOSS scene WANTS things to be taped together because their main thing is random tinkering.
A guarantee is only as good as the willingness to honor it. There are great ideas and some good implementations in systemd, but when the people behind it have a pattern of refusing to fix (and sometimes even acknowledge) show-stopping bugs, it makes me apprehensive about relying on it.
Again, I didn't want my comment to start a heated discussion about systemd, but inevitably that happens. If I had praised it someone else would have come along to tell me how much it sucks (I don't think it sucks, personally, I just have issues with its current development process).
-----
Adding "hacks" but not testing to ensure said hacks don't cause issues:
Lennart Poettering 2014-02-21 13:49:25 UTC
To make this work we'd need a patch, as nobody of us tests this.
Comment 3 Michael Shigorin 2014-04-04 06:30:57 UTC
Hope all of you either test all the combinations or do not break at will those you don't have the time and inclination to test, at least in system-wide components that are not specific to systemd, while pushing the latter hard.
Comment 4 Lennart Poettering 2014-04-04 14:56:43 UTC
Well, cgroups-less kernels are explicitly not supported by systemd. However we added some hacks to allow it to boot to a certain degree even if a lot of things will not work correctly afterwards. In this mode when you boot you will actually get a warning on screen and bootup is delayed by 10s to make sure the user understands this.
Now, this mode recently broke, and it will segfault early on. I am happy to take a patch to 'fix' this again, but I will not work on this as i dont run kernels like this, and as mentioned its not really supported anyway...
Another option is to simply be honest amd stop supporting in entirely, and refuse booting completely. And I figure this is what I will eventually do if nobody cares enough to send me a patch to fix that segfault.
I can't figure out what the problem here is, are you trying to run systemd with a kernel with cgroups compiled out? I don't see how that's a show stopping bug, from the discussion there it was never supported.
No, I'm not. I'm satisfying the other person's request for sources with examples I've come across in the past. In this case it was not about cgroup-less kernels but about Poettering's and Sievers' attitudes towards fixing the issue.
This is why I don't like to talk about systemd on any internet forum; it always leads to people like you ready to attack any position around the subject, and me having to defend a position I don't even hold (I don't think systemd sucks, I think its developers could do better though). I am done with this thread.
I'm not attacking you or asking you to defend a position, I'm asking for clarification because I legitimately do not understand what the issue is. I totally agree with you, it is not helping anyone to become defensive over this. I don't understand what the attitude was, it seems to have been fixed 8 years ago? Did I miss something?
It's reasonable to have the opinion that juggling chainsaws is a dumb idea, even before you've learnt the techniques for making it slightly less dangerous.
Is that really any dumber than doing any similarly dangerous industrial jobs that require a lot of training? Or something else dangerous in entertainment like being a Hollywood stuntman, or being Siegfried & Roy? I'm sure you could get a lot of money for having that skill if you did it in the right place.
>is way too complex for the given functionality, and is completely unneeded in the first place--yes, get rid of the damn thing. Unless of course you enjoy getting "your" system OWNED and dominated by bad actors.
This is a rather nonsense statement. Polkit (or something like it) is needed if you want to have those macOS-style "program A wants to have permission to access privileged resource B" security prompts in the GUI. It's about as complicated as any similar solution needs to be for that use case. Perhaps you find these to be annoying and you disable them so they always succeed, but with that you've effectively given every program permanent suid root access. Definitely simpler, but can you say it's less of a security nightmare? I wouldn't. Yes there are risks of vulnerabilities in any security layer, but without them you've got no security layer at all.
If those checks always fail, you've now lost that functionality to do anything requiring elevated permissions and made your system less useful. You could get it back by installing a suid root tool like sudo/doas but that opens the same hole again that elevates these problems from a crash into a CVE.
I don't want or need popup permission prompts. If something needs to run as root, I run it as root from the console, as God intended. In the process I am assuredly avoiding all sorts of potential security vulnerabilities, such as this polkit code which is not installed on my system. Now get off my lawn.
>Wouldn’t it be great for FreeBSD to be the first OS to have a release that was actually, truly finished?
I don't mean this in a rude or dismissive way but these comments make me want to pull my hair out. Deciding your software has a fixed scope and is finished doesn't stop the wheels of progress from turning. Worst case, the rest of the world will decide the scope you chose was crap, for reasons beyond your control, and then your project is dead. I get that it is an engineer's fantasy to build a theoretically "perfect" system but such a thing can't exist in practice. I think you'd have a better chance of proving P=NP or something.
I don’t mean finish FreeBSD forever and go home - I mean finish a release.
Set some goals, release software that achieves those goals, and keep fixing bugs that are found.
If you have some new goals (support new hardware, add new feature), work on those in the next release. But don’t abandon the old release, because it still works to achieve the original goals.
What I’m suggesting to avoid is the situation where a bug is found and the user is told “it’s fixed in the next release”. If the bug compromises the goals of a release, it should be fixed in that release!
Sure you’d have to support old releases for much longer, but that’s not the hard part.
The hard part is deciding what the goals are in a precise and coherent way (for this purpose, goals should be the set of promises made to the user, which when broken give rise to a bug). I don’t think any large software project has good discipline here. I don’t think it’s been done before for an OS. But I’m talking about differentiation here.
Thanks for the clarification. In practice what that means to me is you need more people backporting fixes to the old branch. My experience: it's boring, thankless work and it doesn't pay unless there is some serious investment behind it, think heavily-audited systems deployed in government offices that have to stay the same for decades.
There is a good reason for new features. But it might be nice if those features came as part of an official set of extensions around a stable core, to get the best of both worlds.
Not necessarily. They're all features that currently exist in the core product, making that product larger and more error prone. Thus, the support story is either the same, or smaller if one of those features isn't activated.
Having them run as extensions doesn't mean that there's a public extension API, you can keep that interface all to yourself. It means that from the developer's perspective, there's a core offering that the most senior members can handle, but the smaller features are both bundled, and can be more easily passed to other teams.
It's the same idea behind using libraries, instead of shoving all the code into one place. But it forces you to have a single structured interface to extend the product, instead of touching every other file when you want to add something.
Sure, you can do all that and set it up manually. I'd love to be corrected here but last I checked this was not done automatically in any BSD. Systemd recognizes this is so common that it does it automatically for every service using the Linux equivalent (cgroups). IMO now that we have these tools, every sysadmin is always going to want to use cgroups/jails for every service all the time and never want to use pidfiles because pidfiles are tremendously broken, error-prone and racy.
Even with systemd one may need to deal with pid files for services with more than one process.
Systemd has heuristics to detect the main process to send the kill signal or detect a crash, but it can guess wrong. Telling it the pid file location makes things reliable.
Plus creation of a pid file serves as a synchronization point that systemd uses to know that the process is ready. The latter is useful when the service does not support systemd native API for state transition notifications.
And the best thing is that even if systemd has to be told about pid files, one never needs to deal with stalled files or pid reuse. Systemd automatically removes them on process shutdown.
A pid file is never actually reliable though. Since the supervised process has control over it, it can write any number it wants in there and trick the service manager into signaling the wrong process. As long as the process is not root and can't escape its own cgroup, systemd's pid detection is going to be less error-prone in basically every case.
I can't stress this enough. Pid files are really bad. The fact that we used to have to use them is a flaw in the OS design. Using them for startup notification is also a hack in and of itself. The kernel has enough information to fully track lifecycle of these processes without writing information into files that are inherently prone to race conditions, and we now have better APIs to expose this information, so we shouldn't need to use these hacks anymore. I don't think there is any Unix-like system left that considers the old forking daemon style to be a good idea, and systemd's handling of pidfiles is really just a legacy compatibility thing.
Not calling you out directly as you're not responding to me, but it's really condescending to always get told how I don't understand because I levied some criticism. I first read the bitcoin paper in 2009. I've seen all the twists and turns the whole space has gone through. It didn't impress me back then and it doesn't impress me now. If I had received one good faith explanation for every time someone said "you just don't understand" then we'd all be a whole lot smarter for it and maybe I wouldn't have had to spend so much time reading these papers and getting disappointed.
>How are NFTs not a more decentralized version of digital goods that already exist?
I don't think they are. In practice they also suffer from (d) because the large majority of NFTs appear to be traded exclusively on Opensea. I don't expect this to change at all because any system like this requires some kind of centralized authority to enforce initial ownership of the art before it's placed on the chain, otherwise you get people selling stolen art. Put another way: there is no value to anyone in having alternate trading platforms for these goods, all value is derived from being verified by a particular platform and baked into that platform. It's the same for video game goods, e.g. there is no value in trading a Fortnite dance outside of Fortnite.
Ownership attestation is a pretty common service. Law companies do the same thing for home titles during real estate purchases, and there's definitely more than one provider of that service!
> there is no value to anyone in having alternate trading platforms for these goods, all value is derived from being verified by a particular platform and baked into that platform
Some value is derived from being verified. People sell stolen merchandise and art all the time, albeit at a discount to actual price. And there's nothing intrinsic to that verification that requires Opensea.
If there were an equally trustworthy provider, or even a provider that offered better title insurance, why would people still use Opensea?
> there is no value in trading a Fortnite dance outside of Fortnite
And here's where I think the slightly interesting component is. Isn't there?
If Epic says "ownership of this digital thing gives you this other thing in game", imagine there are two ways to trade that digital thing: (1) within Epic's internal platform, or (2) on an open Blockchain.
Doesn't it stand to reason that (2) is a clearer ownership claim, with less control, and therefore more valuable? And if it's more valuable, then isn't Epic incentivized to sell their digital goods on Blockchain (and get better prices for them) than their internal platform?
>Ownership attestation is a pretty common service. Law companies do the same thing for home titles during real estate purchases, and there's definitely more than one provider of that service!
Sure, but now we're back to talking about properties of the good old common law legal system, which in some ways is already decentralized. It's not benefiting from anything provided by blockchains and crypto.
>If there were an equally trustworthy provider, or even a provider that offered better title insurance, why would people still use Opensea?
To me, it's the same reason everyone still uses Amazon. Blockchains don't change this dynamic.
>If Epic says "ownership of this digital thing gives you this other thing in game", imagine there are two ways to trade that digital thing: (1) within Epic's internal platform, or (2) on an open Blockchain.
Public blockchains do not provide any additional value here. The only important part is if there is consensus between the two parties to agree that the digital thing should mean something in both places. A public "trustless" blockchain is just noise as far as this goes. The whole thing doesn't work if there is no trust between the two parties to agree that token A should correspond to both item B and item C.
>Doesn't it stand to reason that (2) is a clearer ownership claim, with less control, and therefore more valuable? And if it's more valuable, then isn't Epic incentivized to sell their digital goods on Blockchain (and get better prices for them) than their internal platform?
I don't see how this is the case. If I'm not mistaken, you're talking about transferring an item from an Epic game to another game. That means Epic gets the initial payout for the item and the company making the other game gets nothing but still has to expend time and money supporting items that Epic got paid for. I can't see why they would agree to that.
The ownership claim also isn't clearer, both companies could still just decide to shut down their games simultaneously or retire those items and now you're left with nothing.
I wouldn't suggest giving those permissions to your user because it opens up the possibility of a denial of service. With those permissions, any program running as your user can spawn lots of realtime threads that can take over the scheduler and lock the system up. This was detailed in the rtkit announcement, and preventing it is the reason rtkit exists: http://lalists.stanford.edu/lad/2009/06/0191.html
Maybe realtime audio is not important to you, and that's fine. But it's never as simple as "delete these things and now I have a secure system", you may be trading off security elsewhere to get that. Please also note that pkexec is not required to use polkit. You can remove pkexec and still have a functioning polkit installation and still use all those other daemons too. For a really secure system you may want to remove all suid binaries anyway and only use polkit or SELinux or something.