2ad8850398
- When policies are allocated, the ipc target path goes through symlink resolution. The result is used as the canonical for matching pids to policies at runtime. In particular, this matches up with the target of the `/proc/<pid>/exe`. - There's a possible race condition if this isn't done correctly, read below. Originally, validate_ipc_target() always tried to resolve its argument for symlinks, and returned a parogram target string if it validates. This created a possible race condition with security implications. The problem is that get_feature_policy() first independently resolved the policy target in order to check whether a policy already exists. If it didn't find any, it called alloc_feature_policy() which called validate_ipc_target() which resolved the policy target again. In the time between the two checks, the symlink could be altered, and a lucky attacker could fool the program into thinking that a policy doesn't exist for a target, and then switch the symlink to point at another file. At the very least this could allow him to create two policies for the same program target, and possibly to bypass security by associating the permissions for one target with another, or force default permissions to apply to a target for which a more specific rule has been configured. So we don't that. Instead, the policy target is resolved once and that result is used for the rest of the lookup/creation process. |
||
|---|---|---|
| CMake | ||
| assets | ||
| common | ||
| completions/zsh | ||
| contrib | ||
| include | ||
| protocols | ||
| security.d | ||
| sway | ||
| swaybar | ||
| swaybg | ||
| swaygrab | ||
| swaylock | ||
| swaymsg | ||
| wayland | ||
| .clang-format | ||
| .editorconfig | ||
| .gitignore | ||
| .travis.yml | ||
| CMakeLists.txt | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| README.md | ||
| config.in | ||
| sway.desktop | ||
README.md
sway 
"SirCmpwn's Wayland compositor" is a work in progress i3-compatible Wayland compositor. Read the FAQ. Join the IRC channel (#sway on irc.freenode.net).
Release Signatures
Releases are signed with B22DA89A and published on GitHub.
Status
- i3 feature support
- IPC feature support
- i3bar feature support
- i3-gaps feature support
- security features
Bounties: sponsor features or get paid to write them
Installation
From Packages
Sway is available in many distributions. Try installing the "sway" package for yours. If it's not available, check out this wiki page for information on installation for your distributions.
If you're interested in packaging Sway for your distribution, stop by the IRC channel or shoot an email to sir@cmpwn.com for advice.
Compiling from Source
Install dependencies:
- cmake
- wlc
- wayland
- xwayland
- libinput >= 1.6.0
- libcap
- asciidoc
- pcre
- json-c
- pango
- cairo
- gdk-pixbuf2 *
- pam **
- imagemagick (required for image capture with swaygrab)
- ffmpeg (required for video capture with swaygrab)
*Only required for swaybar, swaybg, and swaylock
**Only required for swaylock
Run these commands:
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_SYSCONFDIR=/etc ..
make
sudo make install
On systems with logind, you need to set a few caps on the binary:
sudo setcap cap_sys_ptrace=eip /usr/local/bin/sway
sudo setcap cap_sys_tty_config=eip /usr/local/bin/sway
On systems without logind, you need to suid the sway binary:
sudo chmod a+s /usr/local/bin/sway
Configuration
If you already use i3, then copy your i3 config to ~/.config/sway/config and
it'll work out of the box. Otherwise, copy the sample configuration file to
~/.config/sway/config. It is usually located at /etc/sway/config.
Run man 5 sway for information on the configuration.
My own dotfiles are available here if you want some inspiration, and definitely check out the wiki as well.
Running
Instead of running startx, run sway. You can run sway from within X as
well, which is useful for testing.