[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Perfect Jessie is something like this...

On 10/27/2014 12:15 PM, Christian Seiler wrote:

Am 27.10.2014 15:05, schrieb Dimitrios Chr. Ioannidis:
Btw. the commit you are referencing just updated the init script, the
change in libuuid was done over 2 years ago:
<https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/libuuid/src/gen_uuid.c?id=ea4f8845f0241c714f9487ece5bb6900fc18a9e0>

That all said: I can understand why the util-linux people wanted to get
rid of the old on-demand mechanism: it's potentially error-prone and may
leak context from the program using libuuid into uuidd.

Say, for example, you put the daemon using libuuid into a cgroup - not
with systemd, but with for example cgconfig. And then that daemon starts
uuidd because it's the first to request a UUID. uuidd will then live in
the same cgroup as the daemon. If the administrator then uses the
'freezer' cgroup to atomically stop the entire service that initially
started uuidd, then uuidd will get stopped alongside with it as
'collateral damage'. And then other services using it will block because
uuidd is still running but they have to wait until it responds again.

This just being one example of context being leaked. Some of this
context could be cleaned up if uuidd were setuid root (and not setuid
uuidd), but not all of it necessarily.
From what you write it's not clear if a) there is an unavoidable security threat in all use cases, and b) there is no way the systemd replacement can co-exist with on-demand UUID in the same executable. I'll assume no in both cases for now. I'll leave alone the issue of whether the script-workaround is a complete functional replacement of the library version.
Then if I read you correctly, the old mechanism may not work with a promised future kernel security feature, but could be working securely now in some use cases, albeit as a hack. If that's right, then the way it was removed is the problem. 


Now, this probably will not have been a problem in your specific case.
So yes, you lost a feature there. But put yourself in the perspective of
the developers of util-linux:

  - drop an error-prone and potentially security-relevant mechanism for
    on-demand startup
  - add support for on-demand startup that will work on a large number
    of installations (systemd being quite prevalent already then)
  - on all other installations: it will now have to be started from the
    very beginning

Obviously, the latter part is not optimal for you, but uuidd will keep
working on your system,  so I don't see what the huge problem is.
Except that the work around won't be in Jessie AFAICT. The parent poster has to waste time tracking it down the script and background information, assume it's untested, hope that it works, and hope that the relevant messages explaining it have not expired from the mailing list archives (util-linux-ng). He's mostly on his own, fixing a problem that probably should not have happened in the first place, if my hypothesis is correct. Even if the script were supplied and works as advertised, it still could mean upgrade breakage, depending on the use case.
The possibility of vendor lock-in is hard to ignore in cases like this. I think this one could be related to the bluez coupling issue, but I have not explored that possibility. My concern would be how many backwards-incompatibility cases like this are lurking in Jessie? Are more being added each day?
Reply to: