Yes probably not.

A quick experiment:

localhost ~ # su chronos
chronos@localhost /root $ metrics_daemon --nodaemon
[ERROR:vmlog_writer.cc(171)] Couldn't set permissions for /var/log/vmlog: Operation not permitted
[ERROR:file_util_posix.cc(334)] CopyDirectory() couldn't create file: /var/log/vmlog/vmlog.PREVIOUS
[ERROR:daemon.cc(98)] Unable to create symbolic link from /var/log/vmlog/vmlog.LATEST to /var/log/vmlog/vmlog.20171107-102141: File exists
[ERROR:file_util_posix.cc(334)] CopyDirectory() couldn't create file: /var/log/vmlog/vmlog.1.PREVIOUS
[ERROR:vmlog_writer.cc(117)] Failed to open file: /var/log/vmlog/vmlog.20171107-102141: Permission denied
[ERROR:vmlog_writer.cc(280)] Writing to vmlog failed.

In fact if I recreate /var/log/vmlog with owner chronos, this runs with no errors.

Do you recommend using chronos or creating a separate user?

it should run as a dedicated user/group.  if there are files that we need to share write access with Chrome (i vaguely recall there being a dropbox method for queuing stats for Chrome to process), the user can be in the chronos-access group.

Mmm, there's going to be a migration issue.  Some files that persist across reboots are root-owned. 

[FATAL:persistent_integer.cc(63)] Check failed: fd >= 0. cannot open /var/lib/metrics/Platform.DailyUseTime for writing: Permission denied
/usr/lib64/libbase-core-395517.so(base::debug::StackTrace::StackTrace()+0x13) [0x7f6bcdf99d43]

Aborted (core dumped)

shouldn't be too big a deal to handle in the init script

probably should sketch out the paths that metrics_daemons care about, whether they're internal only, and what other processes (if any) need access.  then we can figure out the right security knobs to turn.

this is a great example of why retroactively sandboxing is painful/dangerous :).
(not blaming anyone)

We can fix those files in an init script (just change their mode) but that code will linger because of the usual problem of devices that aren't used for a long time, and because we can skip releases (i.e. we might never boot a specific release with the migration code).

that's fine.  the paths in question are not large (so `find` and globs won't be expensive), and metrics_daemon isn't in the critical path.

if you do want to make it an upgrade-only thing, installer/chromeos_postinst.cc can handle all of these types of things, and there won't be any noise at boot.

So doesn't the code still have to linger in installer/chromeos_postint.cc to handle merged updates?

wrt lingering, the time would be the same.  wrt effective overhead, installer/ would be lower as it would only execute once-per-OS-upgrade instead of the init once-per-boot.

i elaborated more on the mailing list thread:
https://groups.google.com/a/chromium.org/d/topic/chromium-os-dev/hZ7Km5T0GY4/discussion

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot