gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] RFC2783 vs TIOCMIWAIT, PPS on NetBSD


From: Greg Troxel
Subject: Re: [gpsd-dev] RFC2783 vs TIOCMIWAIT, PPS on NetBSD
Date: Fri, 01 Nov 2013 09:05:20 -0400
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.4 (berkeley-unix)

Andy Walls <address@hidden> writes:

@esr: Certainly there is concern about retaining privileges, but either
gpsd has to not work or retain privileges to handle various situations.
I suppose this could lead to a privsep architecture, but hopefully not.

> On linux all the RFC2783 time_pps_*() functions funnel through here:
>
> http://lxr.free-electrons.com/source/drivers/pps/pps.c#L67
>
> To call time_pps_setparams() to set things up (like which edges you
> want to capture) requires root, or the POSIX capability CAP_SYS_TIME
> to be retained after you drop root.

RFC2783 says that to call setparams the process must be able to write to
the device, which is very different language than with binding pps to
the kernel clock, where it says something that sounds like "root, but we
don't want to use that word in an RFC".

From RFC2783, I can't tell if setparams should affect only the current
instance of the device, or others that also have it open.
From quickly reading the NetBSD code, setparams looks to be
unprivileged.

> To call time_pps_fetch(), the underlying PPS_FETCH ioctl() call does
> not seem to impose additional permission checks for admin privledges
> or capabilities.

This is also consistent with RFC2783.

RFC2783 does state that binding pps to the system clock is privileged,
which makes sense, and CAP_SYS_TIME.

> I don't know how distributions normally set the permissions on
> /dev/pps? nodes though.

On BSD, the pps calls can be made on file descriptors, and are only
useful when those fds correspond to devices that have pps support, which
is currently real serial ports and I think parallel ports.  This is
consistent with RFC2783, section 3.4.1, which says that the pps calls
should be made on fds corresonding to special files, but which special
files work is out of scope.

ntpd expects /dev/ppsN, and the documentation doesn't explain what that
means.  But I made a symlink pps0 -> dty00 (i386 com0 port at 0x3f8).
ntpd successfully invoked the (BSD-specific, hidden behind the
procedures in RFC2783) pps ioctls, didn't see any transitions, and
declared the pps device non-working.

What happens on Linux if one uses the RFC2783 procedures on a serial
port (or usb serial tty) that has a pps device?  Does that work?

I suspect FreeBSD's pps code is very similar to NetBSD's, perhaps a bit
newer.

Unless I'm missing something, in the docs I think we need to treat the
notion of /dev/ppsN as Linux-specific.

Attachment: pgpje87wHChwS.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]