Re: RTC wakealarm write-only, still has 644 permissions

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

 



David Brownell wrote:
On Friday 30 November 2007, Pavel Machek wrote:
It's not an issue of accidental writes, it's an issue of there being
no other synchronization for setting those alarms.  Remember that both
RTC_WKALM_SET and RTC_ALM_SET ioctls can set that same alarm, and so
could a different userspace activity ...
We have 3 interfaces to one hardware resource. I do not think kernel
should try to arbitrate it here. There's just one alarm clock with
three interfaces.

Having three interfaces is bad enough ... ensuring that none of
them can ever be used safely would be stupid.


As written, this allows one userspace activity to clobber another if
it does so explicitly, by first disabling the other one and then
setting its own alarm.  But the idea is to minimize "accidents" like
unintentionally clobbering an alarm set by someone else.
Well, I could not get it to work with this "avoid-clobber" feature.

I had earlier pointed out a different issue, whereby "oneshot"
semantics weren't consistently followed.  I've been working on
some patches to address that.  The ACPI bits still need work,
but I'll forward one part soonish.


If I remove "accidental alarm modify" logic, I can actually use rtc to
wake up more than once per boot.
Evidently the alarm isn't being disabled then...

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That's the issue addressed by those patches.  (Specific to rtc-cmos,
not to RTCs on saner hardware.)


I think we should just remove the 'avoid-clobber' logic. If userland
wants to somehow arbitrate access, it can.

Pray tell, *HOW* could it arbitrate?
...

This is really a non-issue in practice.  The thing requires root access,
and there's only a single user at most for it on a given system.

This is used by media boxes to power off (or suspend) between recording times.
And similar stuff.

It might be nice to fix it all, but the current state really isn't hurting anything.

Cheers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux