On Thu, 16.04.15 12:52, Cameron Norman (camerontnor...@gmail.com) wrote: > > It's easy to construct similar examples, for example for timedated, > > where setting the system clock is subject to CAP_SYS_TIME, exactly > > like the underlying system call. Using timedated instead of the system > > call gives you the benefit of syncing things into RTC and some tohers, > > but ultimately it's all about the system clock and should hence be > > protected by the same privilege as the actual system call. Protecting > > the "unsafe" raw system call with fewer privileges than the "safer" > > path through timedated is certainly wrong and the other way round > > to. It should really use the same privs! > > As Andy said about the CAP_SYS_BOOT usage, they should NOT use the > same credential.
Well, an explanation why not would be good. > Setting the raw clock is different from setting the system time > through timedated, and should use different credentials. Well, sure, it's different. But it's ultimately the same operation. And again: allowing the dangerous operation to people with lesser privileges but to require more privileges for the safer operation is simply bogus. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel