Date: Tue, 27 Jun 2017 10:20:31 +0300 From: Anthony Pankov <ap00@mail.ru> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: using rc.subr only by root restriction Message-ID: <1352411842.20170627102031@mail.ru> In-Reply-To: <CAJ-Vmo=QKJS6spOV7SvsgLrzifOD1RCWuf_QvZX%2B_PmULN2yyw@mail.gmail.com> References: <1599987034.20170623182536@mail.ru> <CAJ-Vmon8o2j22SRRyzn7jAqLXtOs-LZnm6HZDOfk2mtmBVz1jg@mail.gmail.com> <18210175522.20170626103248@mail.ru> <CAJ-Vmo=QKJS6spOV7SvsgLrzifOD1RCWuf_QvZX%2B_PmULN2yyw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> May be we can agree at "explicit is better than implicit" principle
>> and do not apply a login class when ${name}_login_class is not
>> declared explicity?
>>
>> It will solve my problem too.
> No, because the whole point of the services at startup was to actally
> get the 'daemon' class. That was the intention all along and what
> happened to things at startup time. My patch was to bring running
> "service" in line with what the system did at startup time.
Ok. This was introduced somewhere later then FreeBSD 9.3 and I've
missed this.
> It sucks - ideally we'd have a service manager that you'd request to
> run things on your behalf and it'd always apply a consistent set of
> things, like login class.
Unfortunately I can't suggest other solution then the proposed
patch. The patch introduce an additional logic - service will start
not in 'daemon' login class if executed as regular user.
But I think this is better then failing with error and eliminating
possibility to use rc.subr library in scripts of regular users.
May be you'll commit it?
-- Anthony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1352411842.20170627102031>