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

[Andy Walls]

Hi Greg:

Thanks for wading through the RFCs.

On Fri, 2013-11-01 at 09:05 -0400, Greg Troxel wrote:
> 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, 

It says more than that.

>From RFC2783 Section 3.4.2:
"A suitably privileged application may use time_pps_setparams() to set
   the parameters (mode bits and timestamp offsets) for a PPS source."

So time_pps_setparams() can require privileges.  The rationale is likely
that someone can muck with system time offsets, which is a security
concern. 

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

Right.

>From RFC2783 Section 3.4.4:

"An application with appropriate privileges may use time_pps_kcbind()
   to bind a kernel consumer to the PPS source specified by the handle."

So time_pps_kcbind() can require privileges.  Again, the rationale is
likely that someone can muck with system time, which is a security
concern. 


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

IMO, RFC2783's doesn't prohibit setparams from being an unprivileged
operation, since it uses the weasel words "suitably privileged".

So NetBSD is technically compliant, if it doesn't require elevated
privileges.


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

Agree.


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

Agree.


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

Yup.  It appears that working on serial device nodes appears to be a
choice the *BSDs made.  I suspect that Linux did not make that same
choice.


> 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 would have to investigate.  My initial suspicion is that it does not
work.

I base this on the existing gpsd code which divines the
correct /dev/pps? node, and on that Linux has a tty line discipline that
is explicitly used for setting up a /dev/pps? device that snoops the DCD
line of a tty. 


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

I think you are correct, but maybe the statement needs to be broader.

Whatever the device node type and name, they have to be treated as OS
specific, since, as you mentioned, RFC2783 decided it was not in the
RFC's scope (Section 3.4.1).

The particular rationale for why Linux uses /dev/pps? is here:

http://lxr.free-electrons.com/source/Documentation/pps/pps.txt#L40

Basically, not all PPS sources are from serial or parallel ports, so
what does one do for the device node for these other sources?


RFC2783 Section 1 does state:

"Although existing practice has focussed on the use of serial lines
 and DCD transitions, PPS signals might also be delivered by other
 kinds of devices.  The API specified in this document does not
 require the use of a serial line, although it may be somewhat biased
 in that direction."

I happen to use GPIO pins and Timer-Counter event-capture pins for PPS
devices at the moment.  Having a device not associated with a TTY is
kind of necessary for me.  (Though I don't need gpsd to worry about them
in my current work.)


Regards,
Andy