On 16/12/2013 22:32, Bill Spitzak wrote:
> Could an api be added so that one client can "give" access to an object
> to another client? This would allow a single secure client to implement
> all the rules for what is allowed to be a screen saver, rather than
> having the rules be in the compositor.
2013/12/17 Bill Spitzak :
> On 12/17/2013 02:38 AM, Giulio Camuffo wrote:
>
>> You can't talk to another client directly, you must always pass
>> through the server (unless you use dbus or some other ipc, of course).
>> And you don't need to give the trusted client a key, you just need to
>> tell t
On 12/17/2013 02:38 AM, Giulio Camuffo wrote:
You can't talk to another client directly, you must always pass
through the server (unless you use dbus or some other ipc, of course).
And you don't need to give the trusted client a key, you just need to
tell the server some client is trusted, using
2013/12/17 Bill Spitzak :
>
>
> Giulio Camuffo wrote:
>>
>> 2013/12/16 Bill Spitzak :
>>>
>>> Could an api be added so that one client can "give" access to an object
>>> to
>>> another client? This would allow a single secure client to implement all
>>> the
>>> rules for what is allowed to be a scr
Giulio Camuffo wrote:
2013/12/16 Bill Spitzak :
Could an api be added so that one client can "give" access to an object to
another client? This would allow a single secure client to implement all the
rules for what is allowed to be a screen saver, rather than having the rules
be in the composi
2013/12/16 Bill Spitzak :
> Could an api be added so that one client can "give" access to an object to
> another client? This would allow a single secure client to implement all the
> rules for what is allowed to be a screen saver, rather than having the rules
> be in the compositor.
Yeah, it's po
Could an api be added so that one client can "give" access to an object
to another client? This would allow a single secure client to implement
all the rules for what is allowed to be a screen saver, rather than
having the rules be in the compositor.
What I thought was something like this:
-
On Mon, 16 Dec 2013 01:51:20 +0100
Sebastian Wick wrote:
> Am 2013-12-16 00:52, schrieb Timothée Ravier:
> > polkit could also be used for the whole process of deciding whether
> > a screenshot action is allowed or not:
> >
> > * The compositor would first request authorization for the
> > scree
Am 2013-12-16 00:52, schrieb Timothée Ravier:
polkit could also be used for the whole process of deciding whether a
screenshot action is allowed or not:
* The compositor would first request authorization for the screenshot
action to polkit;
* polkit would check if the action is legitimate using
On 16/12/2013 00:21, Timothée Ravier wrote:
> Thus packaged screenshot applications can include a privileged setup
> step which add a file containing the application full path in a
> directory writable only by root
> (/etc/wayland/accepted-screenshoters.d/appname for example). The
> compositor woul
On 15/12/2013 17:13, Martin Peres wrote:
> On 15/12/2013 01:09, Sebastian Wick wrote:
>> Am 2013-12-13 16:12, schrieb Martin Peres:
>>> What prevents other applications from modifying this setting to true
>>> if they want to
>>> spy on applications?
>>
>> Nothing. But then again if you can write to
On 15/12/2013 01:09, Sebastian Wick wrote:
Am 2013-12-13 16:12, schrieb Martin Peres:
What prevents other applications from modifying this setting to true
if they want to
spy on applications?
Nothing. But then again if you can write to the ini file you can make
the compositor load any code wit
Am 2013-12-13 16:12, schrieb Martin Peres:
What prevents other applications from modifying this setting to true
if they want to
spy on applications?
Nothing. But then again if you can write to the ini file you can make
the compositor load any code with the shell setting.
I don't even think my
Le 04/12/2013 17:38, Sebastian Wick a écrit :
diff --git a/weston.ini.in b/weston.ini.in
index 5181a9e..bc32567 100644
--- a/weston.ini.in
+++ b/weston.ini.in
@@ -65,3 +65,6 @@ path=@libexecdir@/weston-keyboard
#constant_accel_factor = 50
#min_accel_factor = 0.16
#max_accel_factor = 1.0
+
+
Am 2013-12-10 00:20, schrieb Bryce W. Harrington:
On Wed, Dec 04, 2013 at 05:38:23PM +0100, Sebastian Wick wrote:
This patch adds a screenshooter section with the "restrict-access"
setting which is on by default and is the current behavior of weston.
When turning it off, all clients can use the
On Wed, Dec 04, 2013 at 05:38:23PM +0100, Sebastian Wick wrote:
> This patch adds a screenshooter section with the "restrict-access"
> setting which is on by default and is the current behavior of weston.
> When turning it off, all clients can use the screenshooter protocol.
> This makes screen cap
On Wed, 4 Dec 2013 17:38:23 +0100
Sebastian Wick wrote:
> This patch adds a screenshooter section with the "restrict-access"
> setting which is on by default and is the current behavior of weston.
> When turning it off, all clients can use the screenshooter protocol.
> This makes screen capturin
This patch adds a screenshooter section with the "restrict-access"
setting which is on by default and is the current behavior of weston.
When turning it off, all clients can use the screenshooter protocol.
This makes screen capturing for clients easier because they don't
have to be started by westo
18 matches
Mail list logo
