[Openicc] GSoC 2013 preparations

[Richard Hughes]

On 19 March 2013 09:34, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> As daemon yes. But they can write system wide settings. E.g. Argyll has
> /etc/xdg/color.jcnf for that.

How does Argyll write to a root:root directory without being setuid?

>> * If Oyranos writes to the user ~/.config/color/settings/ how is
>> colord supposed to know that settings have changed?
> There are no file I/O API's for that? When I copy files with UNIX cp, they
> are instandly seen by GUI file browsers.

It's called inotify, and doesn't work if the process setting the watch
does not have read permission on the target. As a general permissions
issue, daemons are not allowed access to files in /home, and with
SELinux are actively blocked from doing so.

>> * How is argyllcms supposed to set a specific profile to be used on
>> the login screen if it can't write to /usr or /var?
> Why should a CMS not write to that, provided it obtains the needed
> privilegs?

How would it do that, other than being setuid or calling on a daemon
using IPC that does have those permissions?

> A system level configuration will be fallen back to, if no sufficient user
> configuration is provided.

But that's not compatible with the way we want to do this. In GNOME
and KDE you can click a radio box to choose the default user profile
and click a button to set the profile used in the login screen and for
other users. If a specification suggests that users should edit json
files by hand as the root user, I'm not sure that works with the
operating system that exists now.

> A CMS can start searching for a non automatic profile for a device in the
> user path, then in the system path. If nothing was found it searches for a
> automatic profile in first user paths then system ones and if that gives no
> success it falls back to a automatic generated profile or likely sRGB.

Is that policy or configuration? That sounds like an awfully fragile
workaround to me.

Richard