pkgsrc-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Unprivileged FILES_SUBST for rc.d scripts
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.
Home |
Main Index |
Thread Index |
Old Index