Announcement

Collapse
No announcement yet.

KDE Plasma 5.11 Rolls Into Beta With New System Settings, Better Wayland Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Danny3 View Post
    Still no privacy settings?
    Come on guys, it's 2017 and this is more important to have than ever.
    Even web browsers have permissions control for webcam and mike access.
    Disappointing!
    What you're looking for is Flatpak. (Formerly xdg-app, from Freedesktop.org. The same collaboration of DE developers that brough you things like D-Bus and the xdg-open command.)

    It's a successor to distro-specific package managers for applications which run in a desktop session and it implements Android/iOS-like application sandboxing, relying on Wayland to eliminate X11 APIs as a way to escape the sandbox.

    It can sandbox any application, since it relies on a mixture of technologies like cgroups and seccomp, and some applications require no modification at all, since integrations are done within GTK+ or Qt when possible. (Here are blog posts announcing support progress by KDE [2] and GTK+ devs.)

    ...and, even if an application wants/needs "allow everything", it's still in its best interest to use Flatpak because the GTK+ and Qt integrations finally allow Qt applcations and GTK+ applications to share the same desktop-defined Open/Save/Print dialogs.

    Originally posted by elvenbone View Post
    AFAIK neither USB nor PCI(e) devices can be restricted to certain applications, you can just disable them for the whole system.
    Of course they can be sandboxed... you need something to moderate access to a shared resource among multiple programs and whatever does that can handle access control.

    First, you use the IOMMU to ensure that DMA-capable devices can't be used to escape the sandbox by tampering with memory not granted to them.

    For PCI-E devices, you've generally got a more specific driver handling that, such as the GPU driver (search for "GPU virtualization"), network driver (search netfilter, seccomp, cgroups, etc.), etc.

    For USB devices, you don't even get DMA unless you're on USB 3.1. Beyond that, they're like network sockets in that the kernel handles the transport protocol and another kernel module or userspace driver requests to bind to a specific USB endpoint in the same way you'd ask to connect to an IP+Port combo.

    Flatpak already has the Device portal for requesting access to the speakers/camera/microphone. All it would take is either extending the Device portal or adding another portal to allow a Flatpak'd application to specify that it wants to be the exclusive owner of a USB device with a specific VID+PID combination without having to relax the sandbox rules enough to over-grant permissions within /dev.

    Comment


    • #32
      *poke* Unapproved comment?

      Comment


      • #33
        Originally posted by duby229 View Post

        I haven't heard anything about a third alternative. Why would they waste time developing a third alternative, when supporting it would be more work than supporting GBM?
        It's been mentioned occasionally in Phoronix articles over the last year or so.

        As for their rationale, I suspect it has to do with how much code they share between their Linux and Windows drivers. They probably think that, over the lifetime of the driver, supporting GBM would be more work than coming up with some successor.

        Comment


        • #34
          Originally posted by unixfan2001 View Post

          That's not a GNOME issue, that's a conscious Wayland design choice.
          Well I hope they fix it somehow.
          Because it is very annoying that applications don't open where I last closed them the last time.
          It makes the user experience unpredictable and doesn't cater to the preferences of the user.

          I run Ubuntu aardvark daily, which use Wayland but I still use X.Org because it works better.

          Comment


          • #35
            Originally posted by unixfan2001 View Post

            Of course it's up to the compositor but there is no standard protocol for remembering initial window placement.
            You don't need a protocol, that is something entirely up to the compositor. Again, if the compositor doesn't do that, it is completely and totally the compositor's fault.

            Comment


            • #36
              Originally posted by TheBlackCat View Post

              You don't need a protocol, that is something entirely up to the compositor. Again, if the compositor doesn't do that, it is completely and totally the compositor's fault.
              The whole point of Wayland is to use protocols over hard implementations. So yes, you do need protocols.
              Anything else just leads to more fragmentation.

              Comment


              • #37
                Why would a compositor need a protocol to do something? Protocols are required when applications need to tell the compositor to do something. But that's not the case here, the compositor knows each window's position so it can save it / restore it if the user desires that.

                Comment


                • #38
                  Originally posted by Ansla View Post
                  Why would a compositor need a protocol to do something? Protocols are required when applications need to tell the compositor to do something. But that's not the case here, the compositor knows each window's position so it can save it / restore it if the user desires that.
                  Same reason X11 has properties like WM_CLASS and WM_WINDOW_ROLE... to give the compositor reliable primary keys for indexing into its store of persisted window geometries and/or matchable identifiers for its set of custom window-positioning rules.

                  After all, if a multi-window application wants to persist those windows, it's not really reliable to use window titles.
                  Last edited by ssokolow; 19 September 2017, 08:20 PM.

                  Comment


                  • #39
                    And what makes you think they can't be used in Wayland as well? At least WM_CLASS deffinately is: https://mail.gnome.org/archives/comm.../msg00939.html

                    Comment


                    • #40
                      Originally posted by ssokolow View Post

                      Same reason X11 has properties like WM_CLASS and WM_WINDOW_ROLE... to give the compositor reliable primary keys for indexing into its store of persisted window geometries and/or matchable identifiers for its set of custom window-positioning rules.

                      After all, if a multi-window application wants to persist those windows, it's not really reliable to use window titles.
                      Wayland has properties like that too.

                      Comment

                      Working...
                      X