Frederic Fauberteau <triaxx%NetBSD.org@localhost> writes:
>> 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.
Basically, I think it is not supported ("undefined behavior") to mix
bits from different pkgsrc installs.
>> 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).
So you copied it from the privileged install, to another place in the
privileged install. So it seems wrong for it to have anything to do
with your unprivileged isntall, unless you set some other variable to
point it there.
> 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.
So far we have not crossed into thinking about daemon starting for
unprivileged. Part of the point is that daemons setuid to a special
user for isolation, rather than running as the user that invokved them.
And, many daemons need privileges fro binding to sockets, etc. So it's
always seemed to me that unpriv and daemons don't mix.
It strikes me as more or less a bug for an unprivileged install to do
any of the setuid stuff. But we don't patch that out, or omit those
packages. That seems like too much work for the benefit and unfriendly.
>> 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.
What you are doing is mixing two installs, and after you did that well
enough, it was ok.
Perhaps, programs that normally use privileges should be marked
NOT_FOR_UNPRIVILEGED, but that seems not useful for testing. Instead, I
guess I'd suggest that people not expect that packages that typically
use privileges when built unprivileged will do the right thing.
If you want to construct a test case where only the unpriv install is
used, then I'm happy to think about that. But mixing two installs takes
you off the rails of what I think should be fixed or explained -- sort
of if it breaks you get to keep both pieces sort of comment.
I don't mean to criticize your for trying; people who understand what
they are doing can do all sorts of useful things even if they are
technically undefined behavior.
Attachment:
signature.asc
Description: PGP signature