From b0d97eec09493cf386b9e1cd851653c939018721 Mon Sep 17 00:00:00 2001 From: BEEDELL ROKE JULIAN LOCKHART Date: Wed, 1 Sep 2021 12:57:30 +0100 Subject: [PATCH 1/2] Orthographic improvement. --- README.md | 18 ------------------ readme.md | 18 ++++++++++++++++++ 2 files changed, 18 insertions(+), 18 deletions(-) delete mode 100644 README.md create mode 100644 readme.md diff --git a/README.md b/README.md deleted file mode 100644 index 5f5cfaf..0000000 --- a/README.md +++ /dev/null @@ -1,18 +0,0 @@ -# Use - -- get snap with `zsync http://metadata.neon.kde.org/snap/plasma_5.9_amd64.snap.zsync` -- install `sudo snap install --force-dangerous --devmode plasma_5.9_amd64.snap` -- this is only necessary when the snap was newly installed/reinstalled - - check `snap list` for installed rev of plasma snap (changes on each install). e.g. `x8` - - copy the `bin/` directory from the repo into $HOME/snap/plasma/REVISION/ -- run (currently runs a bash) `dbus-launch snap run plasma` -- setup environment `$HOME/bin/envo` -- at this point startplasmacompositor would work etc. -- simple test in xsession `kwin_wayland --xwayland` should bring up a black wayland window - -# Misc - -- the bin/ stuff is a hack so the snap doesn't have to rebuilt every time the environment needs to be expanded etc. -- this uses a patched xwayland. xkb/ddxLoad.c in xorg is hardcompiling the xkbcomp path to /usr/bin, the patched build simply strips the pathing so xkbcomp is resolved from $PATH (nb: this is a security leak). There is a relocatibility feature resolving xkbcomp's location relative to the server binary, but it is only implemented and used in the windows server right now. -- kinit hard-compile paths in start_kdeinit and start_kdeinit_wrapper. the entire pile of binaries seems a bit weird because in part is claims setuid is involved yet none of the involved binaries actually has the setuid set it seems. start_kdeinit does however oom_adj, whether or not that actually works is unknown given it has no setuid AND it seems to utterly ignore return values so I am guessing it probably does not work. -- kinit has patches to turn the hard-compiled paths into lookup. for wrapper this lookup is relative within same-dir, for start_kdeinit (forks kdeinit) this needs to go through $PATH though. this would be a security hazard if it was setuid and passed that own to a fork but given it isn't to begin with this is probably also fine... diff --git a/readme.md b/readme.md new file mode 100644 index 0000000..3050893 --- /dev/null +++ b/readme.md @@ -0,0 +1,18 @@ +# Usage: + +- Visit `zsync http://metadata.neon.kde.org/snap/plasma_5.9_amd64.snap.zsync` to acquire the snap package. +- Execute `sudo snap install --force-dangerous --devmode plasma_5.9_amd64.snap` to install the snap package. +- This is only necessary when the snap was newly installed/reinstalled: + - Execute `snap list` to observe any installed revisions of `plasma-desktop` (modifications during each installation) such as `x8`. + - Copy the `bin/` directory from the repository into `$HOME/snap/plasma/REVISION/`. +- Execute (currently runs a bash) `dbus-launch snap run plasma` +- Configure environment `$HOME/bin/envo`. +- Now, startplasmacompositor, etcetera, should be operational. +- One simple test in `xsession` `kwin_wayland --xwayland` should create one black Wayland window. + +# Miscellany: + +- The `bin/` stuff is a hack so the snap doesn't have to rebuilt every time the environment needs to be expanded, etcetera. +- This is using one patched `xwayland`. `xkb/ddxLoad.c` in `xorg` is hardcompiling the `xkbcomp` path to `/usr/bin`. The patched build simply strips the pathing so that `xkbcomp` is resolved from `$PATH` (this is not secure). There is a relocatibility feature resolving the location of `xkbcomp` relative to the server binary, but it is only implemented and being used by Windows Server currently. +- `kinit` hard-compile paths in `start_kdeinit` and `start_kdeinit_wrapper`. The entire pile of binaries is appearing to be somewhat weird because in part is claims `setuid` is involved yet none of the involved binaries actually has the `setuid` set apparently. `start_kdeinit` does however `oom_adj`, whether or not that actually is operational is unknown, because it has no `setuid` *and* it is appearing to utterly ignore return values, so I am guessing that it is not able to operate, probably. +- `kinit` is having patches to turn the hard-compiled paths into lookup. For wrapper this lookup is relative within `same-dir`, whereas for `start_kdeinit` (forks `kdeinit`) is requiring redirection through `$PATH`. This would be a hazardous securitywise if it was `setuid` and passed that own to any forks, but because that it is not to begin with, this is probably acceptable. From 20a7766c08070d72d7a4c91d5db83566ab4a673f Mon Sep 17 00:00:00 2001 From: BEEDELL ROKE JULIAN LOCKHART Date: Wed, 1 Sep 2021 13:01:59 +0100 Subject: [PATCH 2/2] Orthographic improvement. Improvement of grammar and syntax. --- readme.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/readme.md b/readme.md index 3050893..7d324ce 100644 --- a/readme.md +++ b/readme.md @@ -12,7 +12,7 @@ # Miscellany: -- The `bin/` stuff is a hack so the snap doesn't have to rebuilt every time the environment needs to be expanded, etcetera. +- The `bin/` stuff is a hack so that the snap is not requiring to be reconstruction when the environment is requiring expansion, etcetera. - This is using one patched `xwayland`. `xkb/ddxLoad.c` in `xorg` is hardcompiling the `xkbcomp` path to `/usr/bin`. The patched build simply strips the pathing so that `xkbcomp` is resolved from `$PATH` (this is not secure). There is a relocatibility feature resolving the location of `xkbcomp` relative to the server binary, but it is only implemented and being used by Windows Server currently. - `kinit` hard-compile paths in `start_kdeinit` and `start_kdeinit_wrapper`. The entire pile of binaries is appearing to be somewhat weird because in part is claims `setuid` is involved yet none of the involved binaries actually has the `setuid` set apparently. `start_kdeinit` does however `oom_adj`, whether or not that actually is operational is unknown, because it has no `setuid` *and* it is appearing to utterly ignore return values, so I am guessing that it is not able to operate, probably. - `kinit` is having patches to turn the hard-compiled paths into lookup. For wrapper this lookup is relative within `same-dir`, whereas for `start_kdeinit` (forks `kdeinit`) is requiring redirection through `$PATH`. This would be a hazardous securitywise if it was `setuid` and passed that own to any forks, but because that it is not to begin with, this is probably acceptable.