Re: Unprivileged FILES_SUBST for rc.d scripts

[Frederic Fauberteau <triaxx%NetBSD.org@localhost>]

Greg Troxel writes:
> Frederic Fauberteau <triaxx%NetBSD.org@localhost> writes:
>> Maybe there is something I did not quite understand and I apologize
>> for that. I installed databases/postgresql13-server from an
>> unprivileged bootstrapped pkgsrc. In rc.d/pgsql file, there is a
>> pgsql_initdb function that contains this part of code:
>>     /bin/mkdir -p -p ${pgsql_home}
>>     true ${pgsql_user} ${pgsql_home}
>>     true ${pgsql_group} ${pgsql_home}
>>     /bin/chmod 0700 ${pgsql_home}
>> that corresponds to the file substitution of:
>>     @MKDIR@ -p ${pgsql_home}
>>     @CHOWN@ ${pgsql_user} ${pgsql_home}
>>     @CHGRP@ ${pgsql_group} ${pgsql_home}
>>     @CHMOD@ 0700 ${pgsql_home}
>> whereas in a privileged /usr/pkg tree, the resulting code is:
>>     /bin/mkdir -p -p ${pgsql_home}
>>     /usr/sbin/chown ${pgsql_user} ${pgsql_home}
>>     /usr/bin/chgrp ${pgsql_group} ${pgsql_home}
>>     /bin/chmod 0700 ${pgsql_home}
> 
> That's a very interesting question.
> 
> An unprivileged pkgsrc cannot add new users and groups to the system.
> So why are they there, unless you also have a privileged install?
I have a unprivileged pkgsrc on my desktop host:
  - to test building packages without break my main (privileged) pkgsrc at /usr/pkg
  - to test unprivileged pkgsrc
The rc.d file for privileged pkgsrc was picked up from another host running postgresql.

> With an unprivileged install, running daemons that are suid or start as
> root and setuid to some specific uid, and use permissions schemes, don't
> really make 100% sense.  I can see the "build package as user and
> install as root" approach, but that's not what unpriv pkgsrc install is.
> 
> How did the rc.d file get installed?  To where?

The rc.d file has been copied from /usr/pkg/share/examples/rc.d to /usr/pkg/etc/rc.d (with rc_directories="/etc/rc.d /usr/pkg/etc/rc.d" in /etc/rc.conf).

> What do you think should happen?  Why?

If service(8) can be run by an unprivileged user, maybe own can test if this user is ${pgsql_user} and prints a message otherwise. Own can also conditionally run ulimit. If service(8) cannot be run by an unprivileged user, maybe own can accordingly prints a message. Actually, I have on idea what is the policy.

> My only guesses other than "don't do that" are
> 
>   all the user/group should be nobody, but then how do programs separate
> 
>   there should be no setuid, and you should only runs these programs
>   under the uid that owns the install

Finally, I set ${pgsql_user} and ${pgsql_group} to existing uid/gid in /etc/rc.conf and I run service(8) as root. It works fine, but not out of the box. It is not a complaint, I would just like to understand well how it should work to potentially add some messages when things should be not done.