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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071130212722.GB1634@elf.ucw.cz>
Date:	Fri, 30 Nov 2007 22:27:23 +0100
From:	Pavel Machek <pavel@....cz>
To:	Mark Lord <lkml@....ca>
Cc:	David Brownell <david-b@...bell.net>, rtc-linux@...glegroups.com,
	kernel list <linux-kernel@...r.kernel.org>,
	Alessandro Zummo <alessandro.zummo@...ertech.it>
Subject: Re: RTC wakealarm write-only, still has 644 permissions

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.
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/