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

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


On Fri 2007-11-30 16:20:58, Mark Lord wrote:
> 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.

Exactly. If you wanted arbitration, just create "rtcd", and make users
talk to it over sockets or something. Actually openmoko has neod,
which does that iirc.

(cesky, pictures)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at
Please read the FAQ at

[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