Richard PALO <richard%netbsd.org@localhost> writes:
> yes, we're talking about 'dbus-daemon --system' here.
>
>> 2) You chose db vs run. So are (at least some of) these files
>> intended to persist across reboots? If so, that's appropriate. If
>> not, they arguably belong in run.
>
> The dbus machine-id is indeed persistent. The pid and system_bus_socket
> are as can be expected run-specific and are created by the dbus-daemon
> process (NB running as DBUS_USER:DBUS_GROUP).
So aside from privilege issues all is ok now?
>> 3) I don't understand how "unprivileged" is related to run.
>> /var/run and /var/db (on NetBSD) are both root-owned and 755. So
>> using them for anything not root involves a subdirectory which is
>> created by root and then set to the the non-root user. This seems
>> to apply to both run and db. With db, it can be created at
>> package install time. With run, it should be done by the rc.d
>> script (or smf).
>
> from the filesystem manpage:
>> /var/run Temporary files which are not needed across reboots. Only
>> root may modify the contents of this directory.
That must be from OpenSolaris :-) On NetBSD hier(7) says:
run/ system information files, rebuilt after
each reboot
But indeed it is root-owned. pkgsrc.txt doesn't really address this,
but in general the pkgsrc hier has always been understood to be cloned
From NetBSD's (which is really *BSD's).
> I believe the issue centers around the fact that legacy rc processing is
> always done as 'root', but in smf if the user= and group= are specified
> non-root they are invoked as such.
Please don't use the word "legacy" to describe the normal approach as
opposed to the new approach you are using that you think is better :-)
In particular, in pkgsrc rc.d is the standard approach, and there has
been no talk of getting rid of it.
> Therefore a non-root process has no means to be able to create files or
> directories under /var/run without elevated privileges (which is just
> the point).
Ah, so the real issue is that in smf there is no way to execute a
preparatory step as root. By putting files in /var/db, pkg_add can do
this (and somehow it's ok for it to be able to do root things, when it's
not ok for smf at boot).q3
> Since $DBUS_HOME is statically created with correct owner permissions,
> this will *always* work, root or non-privileged.
Which is either a fix or a workaround, depending on viewpoint.
> If there is violent disagreement, then I guess the smf scripts could
> invoke the 'root' user and create the /var/run/dbus directory with
> owner DBUS_USER:DBUS_GROUP for the pid and socket file just like the
> rc script does, naturally leaving the security question undealt with.
I am not inclined to make pkgsrc depart from established norms because
smf can't handle a situation that seems normal.
Before we do anything (pretty clearly not for Q3 at this point in terms
of changing paths), I think we need a larger discussion about how smf is
going to deal with the need to execute things as root and what that set
of things is likely to be. Making subdirectories in /var/run is surely
a pretty common thing - looking at a few systems, I see hal and named
also.
But what else will appear? Are we only talking about daemons that don't
need root for any other purpose?
Have you looked at all of OpenSolaris to see if this case appears
outside of pkgsrc? What do they do? (But remember, OpenSolaris hier(7)
!= BSD hier(7).)
In general, the concept of "un-privileged system daemon" is a bit of a
stretch for the traditional Unix model. I'm not arguing against it -
Least Privilege is an improvement, but we have to recognize it as a
departure and think about how to adjust. I would far rather add
support for creating /var/run/foo dirs owned by foo at boot time than to
move directory usage to what seems like the wrong place.
> The attached patch does just that, but I'd like to note that this
> presumes a 'responsable' daemon program...
I really don't understand what you mean by "leaving the security
question undealt with". There's a mechanism apparently (from reading
your new patch), and if the mechanism doesn't work right it should be
fixed. If it does work, it should be ok to use. But again, I don't
want to move pathnames for all of pkgsrc as a workaround for inadequate
support in smf.
Greg
Attachment:
pgpFpcbLTsb96.pgp
Description: PGP signature