Reading the CMOS clock without being root

[Peter Pearson]

I'd like to read the CMOS clock from a Python script, and
what "sudo hwclock -r" prints would be just fine, but it
seems like poor security to run the Python script as root,
and hwclock won't give me the time of day (hee! - sorry) if
it's not run as root.

What's a sensible way to do this?

My best guess is that I write a C-language wrapper for
"hwclock -r" and make it setuid root. Is there a better
way? Thanks for your time.

--
To email me, substitute nowhere->spamcop, invalid->net.

[David W. Hodgins]

On Fri, 07 Jun 2013 19:49:06 -0400, Peter Pearson <ppea...@nowhere.invalid> wrote:

> and hwclock won't give me the time of day (hee! - sorry) if
> it's not run as root.
> What's a sensible way to do this?

Run it as a regular user.

$ /sbin/hwclock -r
2013-06-07T21:59:11 EDT -0.328707 second

You have to specify the path, since sbin is not usually in the
users path.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

[unruh]

On 2013-06-08, David W. Hodgins <dwho...@nomail.afraid.org> wrote:
> On Fri, 07 Jun 2013 19:49:06 -0400, Peter Pearson <ppea...@nowhere.invalid> wrote:
>
>> and hwclock won't give me the time of day (hee! - sorry) if
>> it's not run as root.
>> What's a sensible way to do this?
>
> Run it as a regular user.
>
> $ /sbin/hwclock -r
> 2013-06-07T21:59:11 EDT -0.328707 second
>
> You have to specify the path, since sbin is not usually in the
> users path.
>
> Regards, Dave Hodgins

/sbin/hwclock -r
hwclock is unable to get I/O port access: the iopl(3) call failed.
Probably you need root privileges.

[Bit Twister]

On Sat, 08 Jun 2013 04:49:45 GMT, unruh wrote:

> /sbin/hwclock -r
> hwclock is unable to get I/O port access: the iopl(3) call failed.
> Probably you need root privileges.

How odd.
[junk@wb ~]$ /sbin/hwclock -r
Fri 07 Jun 2013 11:50:57 PM CDT -0.313266 seconds

$ id
uid=500(junk) gid=500(junk) groups=500(junk),81(audio),411(pulse-access)

$ cat /etc/release
Mageia release 3 (Official) for x86_64

[J.O. Aho]

On 08/06/13 01:49, Peter Pearson wrote:
> I'd like to read the CMOS clock from a Python script, and
> what "sudo hwclock -r" prints would be just fine, but it
> seems like poor security to run the Python script as root,
> and hwclock won't give me the time of day (hee! - sorry) if
> it's not run as root.
>
> What's a sensible way to do this?
>
> My best guess is that I write a C-language wrapper for
> "hwclock -r" and make it setuid root. Is there a better
> way? Thanks for your time.
>

Run "hwclock -r --debug" and you will see why you can't use is as
unprivileged user. I would guess the unprivileged user don't have
access to read /dev/rtc

# ls -l /dev/rtc0
crw------- 1 root root 254, 0 May 4 09:49 /dev/rtc0

# chmod a+r /dev/rtc0

$ /sbin/hwclock -r
Sat 08 Jun 2013 08:04:58 CEST -0.156599 seconds

$ ls -l /dev/rtc0
crw-r--r-- 1 root root 254, 0 May 4 09:49 /dev/rtc0


This will not be permanent, next time you reboot it will be back to the
normal unless you set up some rules which will be setting the "correct"
permission values for you.

Note: the debug information will say /dev/rtc, which can be misleading
if your first instance is called /dev/rtc0, this is compiled into the
kernel which name it will have, but hwclock will find it without the
need to specifying which device to use.

--

//Aho

[unruh]

hwclock -r --debug
hwclock from util-linux-ng 2.14.1
hwclock: Open of /dev/rtc failed, errno=16: Device or resource busy.
Using direct I/O instructions to ISA clock.

hwclock is unable to get I/O port access: the iopl(3) call failed.
Probably you need root privileges.

l /dev/rtc*
lrwxrwxrwx 1 root root 4 2013-06-01 10:52 /dev/rtc -> rtc0
crw-rw-r-- 1 root root 254, 0 2013-06-01 10:52 /dev/rtc0

But as root it works fine, and no "device or resource busy", it is is
apparently busy only to user, not root.
It turns out that it was chrony that was hogging rtc. If I killed
chronyd, hwclock did type out the time for user.
I do not understand how a clock could be busy for one user and not
another.

By the way, what is the fraction of a second listed at the end of the
output? the rtc is only good to a second.


>

[Richard Kettlewell]

unruh <un...@invalid.ca> writes:
> I do not understand how a clock could be busy for one user and not
> another.

Once /dev/rtc has been opened, further opens will return EBUSY until it
is closed. Users don’t enter into it. At a guess the other process you
mention doesn’t actually hold it open indefinitely.

> By the way, what is the fraction of a second listed at the end of the
> output?

It’s the length of time it took to read the clock.

--
http://www.greenend.org.uk/rjk/

[Maurice Batey]

On Fri, 07 Jun 2013 22:00:52 -0400, David W. Hodgins wrote:

> Run it as a regular user.
>
> $ /sbin/hwclock -r

$ /sbin/hwclock -r
hwclock: Cannot access the Hardware Clock via any known method.
hwclock: Use the --debug option to see the details of our search for an
access method.

$ id
uid=500(mab) gid=500(mab) groups=500(mab),43(usb),501(vboxusers)

$ cat /etc/release
Mageia release 2 (Official) for x86_64

--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)

[unruh]

On 2013-06-08, Richard Kettlewell <r...@greenend.org.uk> wrote:
> unruh <un...@invalid.ca> writes:
>> I do not understand how a clock could be busy for one user and not
>> another.
>
> Once /dev/rtc has been opened, further opens will return EBUSY until it

> is closed. Users don???t enter into it. At a guess the other process you
> mention doesn???t actually hold it open indefinitely.

Nope, It it completely consistant. Whenever I tried to read it as user,
it did not work, when I read it as root, it did.
I just tried it 10 times as each (root and user) Every time root worked
and user did not.
( and if I run --debug, as user I get

hwclock from util-linux-ng 2.14.1
hwclock: Open of /dev/rtc failed, errno=16: Device or resource busy.
Using direct I/O instructions to ISA clock.
hwclock is unable to get I/O port access: the iopl(3) call failed.
Probably you need root privileges.



>

>> By the way, what is the fraction of a second listed at the end of the
>> output?
>

> It???s the length of time it took to read the clock.
>

[crankypuss]

If I'm not mistaken that's microseconds. The microtime() function in
PHP has had access to this for several years now.

[Richard Kettlewell]

unruh <un...@invalid.ca> writes:
> On 2013-06-08, Richard Kettlewell <r...@greenend.org.uk> wrote:
>> unruh <un...@invalid.ca> writes:

>>> I do not understand how a clock could be busy for one user and not
>>> another.
>>
>> Once /dev/rtc has been opened, further opens will return EBUSY until it
>> is closed. Users don???t enter into it. At a guess the other process you
>> mention doesn???t actually hold it open indefinitely.
>
> Nope, It it completely consistant. Whenever I tried to read it as user,
> it did not work, when I read it as root, it did.
> I just tried it 10 times as each (root and user) Every time root worked
> and user did not.
> ( and if I run --debug, as user I get
>
> hwclock from util-linux-ng 2.14.1
> hwclock: Open of /dev/rtc failed, errno=16: Device or resource busy.
> Using direct I/O instructions to ISA clock.
> hwclock is unable to get I/O port access: the iopl(3) call failed.
> Probably you need root privileges.

That makes it clearer. /dev/rtc behaves as described above; if it can’t
be opened for any reason, hwclock attempts direct I/O (‘cmos’ in its
internal naming scheme). When invoked as mortal, that fails too.

--
http://www.greenend.org.uk/rjk/

[Bit Twister]

On Sat, 08 Jun 2013 17:24:38 +0100, Maurice Batey wrote:
>
> $ /sbin/hwclock -r
> hwclock: Cannot access the Hardware Clock via any known method.
> hwclock: Use the --debug option to see the details of our search for an
> access method.
>

> $ cat /etc/release
> Mageia release 2 (Official) for x86_64

Ah, ha, Can be fixed with a change in /lib/udev/rules.d/50-udev-default.rule
by adding MODE="0644", Example:
SUBSYSTEM=="rtc", ATTR{hctosys}=="1", MODE="0644", SYMLINK+="rtc"
and the quick/temp fix by chmod 644 for either /dev/rtc or if a link,
whatever the link points to.

Future reboots would not need the chmod command.

[Peter Pearson]

On 7 Jun 2013 23:49:06 GMT, Peter Pearson <ppea...@nowhere.invalid> wrote:
> I'd like to read the CMOS clock from a Python script, and
> what "sudo hwclock -r" prints would be just fine, but it
> seems like poor security to run the Python script as root,
> and hwclock won't give me the time of day (hee! - sorry) if
> it's not run as root.

Many thanks to the several helpful people who troubled to
address this question, which turned out (this keeps happening)
to be more complicated than I expected.

Here's the "permissions situation" on my Debian system:

$ ls -l /dev/rtc*
lrwxrwxrwx 1 root root 4 Jun 2 17:41 /dev/rtc -> rtc0
crw------- 1 root root 254, 0 Jun 2 17:41 /dev/rtc0

$ /sbin/hwclock -r --debug
hwclock from util-linux-ng 2.17.2
hwclock: Open of /dev/rtc failed, errno=13: Permission denied.
No usable clock interface found.

Cannot access the Hardware Clock via any known method.

I interpret this to mean that non-root people are forbidden to use
/dev/rtc0, and therefore /dev/rtc. One suggestion was to change
/lib/udev/rules.d/50-udev-default.rule by adding MODE="0644", and
to chmod 644 /dev/rtc0. This leads to the question, How can I be sure
that relaxing restrictions on this device doesn't harm security?
Yes, I can easily imagine that someone defining the default
Debian configuration removed those permissions for No Good Reason;
but unfortunately I'm not competent to declare it so. (Of course,
if granting universal read access is insecure, then at least one
of the respondents is vulnerable.)

For completeness of this record, one respondent found that the chrony
daemon, chronyd, was keeping /dev/rtc open, resulting in a "device or
resource busy" error message instead of "permission denied".

[Peter Pearson]

On Sat, 08 Jun 2013 16:22:03 +0100, Richard Kettlewell wrote:
> unruh <un...@invalid.ca> writes:
[snip]

>> By the way, what is the fraction of a second listed at the end of the
>> output?
>
> It’s the length of time it took to read the clock.

More specifically, I believe that in order to get precision
much finer than the one-second precision available from the
CMOS clock, hwclock watches the CMOS clock until it changes,
while using some other clock to time that delay. So when
hwclock says, for example,

Sun 09 Jun 2013 09:37:14 PM PDT -0.547102 seconds

I think it's saying, "The CMOS clock just changed from 09:37:13
to 09:37:14, but you issued the hwclock command 0.547 seconds before that."
(This interpretation is vaguely supported by very approximate
experiments involving carefully timing the striking of the <enter>
key.)

[J.O. Aho]

On 10/06/13 06:32, Peter Pearson wrote:

> I interpret this to mean that non-root people are forbidden to use
> /dev/rtc0, and therefore /dev/rtc. One suggestion was to change
> /lib/udev/rules.d/50-udev-default.rule by adding MODE="0644", and
> to chmod 644 /dev/rtc0. This leads to the question, How can I be sure
> that relaxing restrictions on this device doesn't harm security?
> Yes, I can easily imagine that someone defining the default
> Debian configuration removed those permissions for No Good Reason;
> but unfortunately I'm not competent to declare it so. (Of course,
> if granting universal read access is insecure, then at least one
> of the respondents is vulnerable.)

You could create a new group say "clockuser" and in udev chmod to 0640
and set "clockuser" to be the group which is allowed to read, now you
assigning users which you trust to the clockuser group.

The only vulnerability I know of, is you have some badly supported
hardware like say HP Pavilion DV9000 which will freeze when running
hwclock, then you should avoid users to get access to it.

--

//Aho

[unruh]

You were the one that wanted a non-root user to be able to read the rtc.
Now you worry about allowing non-root users to read it. That is
something you will have to come to terms with for yourself. You now know
how to accomplish what you originally wanted.

If you are asking if there is a security problem in having the rtc
readable by anyone, then I cannot think of one. But it is up to you.
(Note that if you do not what everyone to be able to read it, make the
user that wants to read it part of the root group (/etc/group) and make
rtc0 readable by the group.

[unruh]

On 2013-06-10, Peter Pearson <ppea...@nowhere.invalid> wrote:

> On Sat, 08 Jun 2013 16:22:03 +0100, Richard Kettlewell wrote:
>> unruh <un...@invalid.ca> writes:
> [snip]
>>> By the way, what is the fraction of a second listed at the end of the
>>> output?
>>

>> It???s the length of time it took to read the clock.

>
> More specifically, I believe that in order to get precision
> much finer than the one-second precision available from the
> CMOS clock, hwclock watches the CMOS clock until it changes,
> while using some other clock to time that delay. So when
> hwclock says, for example,

The hardware clock raises an interrupt when the second rolls over. Now
Linux screwed up the handling of the interrupt for a while, but that may
be fixed now.

[Jasen Betts]

On 2013-06-10, unruh <un...@invalid.ca> wrote:
> On 2013-06-10, Peter Pearson <ppea...@nowhere.invalid> wrote:
>> On Sat, 08 Jun 2013 16:22:03 +0100, Richard Kettlewell wrote:
>>> unruh <un...@invalid.ca> writes:
>> [snip]
>>>> By the way, what is the fraction of a second listed at the end of the
>>>> output?
>>>
>>> It???s the length of time it took to read the clock.
>>
>> More specifically, I believe that in order to get precision
>> much finer than the one-second precision available from the
>> CMOS clock, hwclock watches the CMOS clock until it changes,
>> while using some other clock to time that delay. So when
>> hwclock says, for example,
>
> The hardware clock raises an interrupt when the second rolls over.

yeah, IRQ8 (also happens 1023 times between roll-overs)

--
⚂⚃ 100% natural

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---