Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

0.14 #1237

Closed
ddevault opened this issue Jun 14, 2017 · 34 comments
Closed

0.14 #1237

ddevault opened this issue Jun 14, 2017 · 34 comments

Comments

@ddevault
Copy link
Contributor

Let's start getting 0.14 out the door.

https://github.com/SirCmpwn/sway/releases/tag/0.14-rc1

Will prepare a changelog later tonight.

@ddevault
Copy link
Contributor Author

ddevault commented Jun 15, 2017

Changelog:

This is a relatively small release with 53 changes from 12 contributors. New features include support for tray icons and support for KDE's Wayland extension for client-side border negotiation. Several smaller features and many bug fixes are also included. Updates to wlc also improve touchscreen support and fix the old extra cursor gdm issue.

Tray icons are now supported via SNI, and Xembed support is in-progress and planned for a future release. Tray icons for programs using the new specification should work correctly, but older programs using Xembed will not. Border negotiation requries participation from the client - a patch for GTK+ is available here. Reminder to self: update wiki page on removing GTK borders

You may have heard that we're replacing wlc, a library that does a lot of low-level plumbing work for Sway. I'm happy to announce that our replacement project, wlroots, is progressing at a great pace - largely thanks to financial support from Nyantec, who offered to sponsor me to work full time on Sway for a while. Additional support has come from supporters of my new Patreon page - many thanks! Dramatic improvements to Sway will be possible when wlroots is ready. Look forward to it!

Changes

New Features

Bugs fixed

@WhyNotHugo
Copy link
Contributor

Tray icons are now supported via SNI, and Xembed

Aren't AppIndicator designed explicitly not to rely on Xorg-specifics? Maybe that's a slightly cleaner target for wayland?
The big downside is that there's very little/poor documentation. :(

Oh, and thanks for all the hard work and to Nyantec for sponsoring this too! 🎉

@ddevault
Copy link
Contributor Author

Some proof of concept work has been done with Xembed - it definitely works, it just requires some finageling. I don't really know much about AppIndicator.

@4e554c4c
Copy link
Contributor

Is appindicator server side? I only see client side bindings. I think it's best to continue to use what we have already, and if it needs expansion for appindicators that can happen.

@soredake
Copy link

appindicators

I really want this for https://github.com/Bajoja/indicator-kdeconnect

@4e554c4c
Copy link
Contributor

Does it not work with this rc? That project's readme says it uses StatusNotifierItem.

@soredake
Copy link

@4e554c4c KStatusNotifierItem is kde only, not working on latest master.

@ddevault
Copy link
Contributor Author

0.14-rc2

Contains only documentation fixes, but I'd still like testing to continue for another week at the least.

@ddevault
Copy link
Contributor Author

0.14-rc3 is out. Contains 3 bug fixes. Please test.

@johalun
Copy link
Contributor

johalun commented Jul 7, 2017

0.14-rc3 unmodified on FreeBSD12-CURRENT with clang 4.0.0
Will investigate further after lunch.

[ 96%] Building C object swaybar/CMakeFiles/swaybar.dir/event_loop.c.o
/home/johannes/dev/sway/swaybar/event_loop.c:99:24: error: comparison of distinct pointer types ('timer_t' (aka 'struct __timer *') and
      'const timer_t *' (aka 'struct __timer *const *')) [-Werror,-Wcompare-distinct-pointer-types]
        if (timer_item->timer == timer) {
            ~~~~~~~~~~~~~~~~~ ^  ~~~~~
/home/johannes/dev/sway/swaybar/event_loop.c:130:17: error: implicit declaration of function 'timer_getoverrun' is invalid in C99
      [-Werror,-Wimplicit-function-declaration]
                int overrun = timer_getoverrun(item->timer);

@johalun
Copy link
Contributor

johalun commented Jul 7, 2017

Hmm I'm getting some weird behavior where the background is treated as a regular window.
I.e., when I start sway and can see the blue background image and as I launch a program, the background is shrunk and moved to left half of the screen while my new window is on the right half of the screen..

@ddevault
Copy link
Contributor Author

ddevault commented Jul 7, 2017

Symptoms typical of an incorrect security configuration. Check the log, it sounds like swaybg doesn't have permission to become the background.

@johalun
Copy link
Contributor

johalun commented Jul 8, 2017

@SirCmpwn What kind of security config? Does swaybg need SUID root? Currently I only set 'sway' binary SUID root.

@ddevault
Copy link
Contributor Author

ddevault commented Jul 8, 2017

Meaning /etc/sway/security.d/*

@ddevault
Copy link
Contributor Author

ddevault commented Jul 8, 2017

man 7 sway-security

@johalun
Copy link
Contributor

johalun commented Jul 8, 2017

I have permit /usr/local/bin/swaybg background in /usr/local/etc/sway/security.d/00-defaults and no error message in the log (output of sway command).

@ddevault
Copy link
Contributor Author

ddevault commented Jul 8, 2017

And swaybg is indeed installed to that location, is owned by root, and is not a symlink?

@johalun
Copy link
Contributor

johalun commented Jul 8, 2017

Hmm, -d gave this:
07/08/17 20:47:39 - [security.c:133] WARNING: unable to read /proc/0/file for security check. Using default policy.

Maybe need some FreeBSDification.

@ddevault
Copy link
Contributor Author

ddevault commented Jul 8, 2017

And sway is reading from /usr/local/etc/sway/*?

@ddevault
Copy link
Contributor Author

ddevault commented Jul 8, 2017

Aha.

@johalun
Copy link
Contributor

johalun commented Jul 8, 2017

Oh, for every mouse event I get
07/08/17 20:47:39 - [security.c:133] WARNING: unable to read /proc/0/file for security check. Using default policy.

@johalun
Copy link
Contributor

johalun commented Jul 8, 2017

Ok, so this is what we need to do:
http://www.masterraghu.com/subjects/np/introduction/unix_network_programming_v1.3/ch15lev1sec8.html

I can implement it on Monday (possible tomorrow Sunday).

@ddevault
Copy link
Contributor Author

ddevault commented Jul 8, 2017

Alright, I'm just going to hold off rc4 until then and ship 0.14 a week after whenever that happens to land.

@johalun
Copy link
Contributor

johalun commented Jul 9, 2017

Great. Just a note, a log output or error message instead of silently failing on non-linux OS would be nice :)

Edit: paste this

static pid_t get_client_pid(int client_fd) {
// FreeBSD supports getting uid/gid, but not pid
#ifdef __linux__
	struct ucred ucred;
	socklen_t len = sizeof(struct ucred);

	if (getsockopt(client_fd, SOL_SOCKET, SO_PEERCRED, &ucred, &len) == -1) {
		return -1;
	}

	return ucred.pid;
#else
	return -1;
#endif
}

@johalun
Copy link
Contributor

johalun commented Jul 9, 2017

@SirCmpwn Hmm, this wasn't so easy after all without modifying the client code. Maybe go ahead with the release while I figure out how to solve this.

@ddevault
Copy link
Contributor Author

ddevault commented Jul 9, 2017

I don't want to break FreeBSD. We should ship a different configuration on FreeBSD that enables more security features by default for all clients.

@johalun
Copy link
Contributor

johalun commented Jul 10, 2017

Simply doing

#ifdef __FreeBSD__
	return IPC_FEATURE_ALL;
#endif

in get_*_policy_mask() and it seems to work fine. For now anyway. Not sure what default policy we should use.

There seem to be a consensus that getting the PID via socket and using that for security is a bad thing. The PID can have changed and is being used by another process so there's a race condition (although time frame for that to happen is minimal...)

@johalun
Copy link
Contributor

johalun commented Jul 10, 2017

Btw, how do I set default config in security config file?

Edit: never mind, found it.
By adding /usr/local/etc/sway/security.d/10-freebsd:
permit * fullscreen keyboard mouse background screenshot panel lock

I achieve the same results.

@ddevault
Copy link
Contributor Author

Yeah, something like 10-freebsd is what I was suggesting. Can you add a file like it (with a comment in the file explaining its necessity) that's installed on FreeBSD systems?

There seem to be a consensus that getting the PID via socket and using that for security is a bad thing. The PID can have changed and is being used by another process so there's a race condition (although time frame for that to happen is minimal...)

Meh, we can assume that a process isn't giving away its i3 IPC handles willy nilly and that even if it did we could probably trust it to not be stupid enough to give it to a process that shouldn't have access to its security permissions.

@johalun
Copy link
Contributor

johalun commented Jul 11, 2017

Yeah, in Sway there shouldn't be any problems. But imagine someone hanging on to a pid of a crashed client, could have some unwanted consequences if the pid is reused by another program.. This will be tricky to solve without having the clients sending pid or binary path info to the compositor :(

Edit: Instead of #ifdef linux maybe we can simply do #ifdef SO_PEERCRED?

@ddevault
Copy link
Contributor Author

Yeah, in Sway there shouldn't be any problems. But imagine someone hanging on to a pid of a crashed client, could have some unwanted consequences if the pid is reused by another program..

This seems unlikely, if not impossible. The file descriptor certainly would not remain valid between the two programs even if they shared a pid.

This will be tricky to solve without having the clients sending pid or binary path info to the compositor :(

This would not work because the clients can lie.

@ddevault
Copy link
Contributor Author

ddevault commented Jul 12, 2017

@ddevault
Copy link
Contributor Author

rc5: https://github.com/SirCmpwn/sway/releases/tag/0.14-rc5

Please actually test this one guys, we're already way behind schedule.

@ddevault
Copy link
Contributor Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

5 participants