From owner-freebsd-hackers@freebsd.org Mon Jun 26 16:04:33 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E9AAD8ADB3 for ; Mon, 26 Jun 2017 16:04:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D848F7E916 for ; Mon, 26 Jun 2017 16:04:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id w126so1820528wme.0 for ; Mon, 26 Jun 2017 09:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gtd3pnN8OI12gJUI+nYvEWoqYFy9jOq5ZoLzwX8S31g=; b=HdJKxfXNbuJ5nJotPToYjCB4JVuacgtQn8yZROFrjWQZHjrFFlzsMfvUI2PZjvFwS2 +PXixzX6hzGQO3u86zkc3R9dfrq9LgaJiLnbttSIOfH72o286SdQ6x2mu2xpkFjWJXto gWimike4xtCYDFDRcUTH5B00AyBCHsIkYjUUuZzoihQdEsVjkEJCixJv9BqRK3RSDIwl CqMIlJmQBMN6+W519EEgsEEFlNze3ekpEJFvbhG+SMFvp19drGCbhxNmwSVaobomupG+ /Lej0DPM7kfSDITqCFxB1pCBzwKqvcQDeWyBHdLrLieF4S/WPfUpW9gi/sOrB0Bf4F74 M+JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gtd3pnN8OI12gJUI+nYvEWoqYFy9jOq5ZoLzwX8S31g=; b=NvtvjLg0Wixx95GjqBPEi0VJBDEViAz3TKgDoDuVBiegAsd4IIvfbj9P1wCSFwRJiD ImYf2S4VFpCwyF8PUYBJQ7jd/OR3Sfj/hh1epDdv1noLMb5irfchPjQYpH+HANog2J8w SB+tiTkwdZktYLd/CXVQQkB/D+jgSMl9Sn/CzSBuSAuHwxGvDHEqmp3rpu1GfsLQUNAa 4+oSY0bK9ACh8fQgfBUpQ6rzKdOSPEg/3GzV7RIEHNKfHH7HYvvwosj3jCWckM3nJDdx 7qfWUdI8H64KUSANz/a//vtnPjTds1U0wWFUgUaXp/zeL1k+9dDv5cp+7oW1xyKl3PwQ 2rPA== X-Gm-Message-State: AKS2vOwZu0K315i19yz2eCryBSoqtYk0viZ5qpe5n1mQem8I/zm1tkT0 tb2GO7+L35FOMd5wjAj0DQO4JBB/QjIs X-Received: by 10.28.166.137 with SMTP id p131mr198858wme.5.1498493070942; Mon, 26 Jun 2017 09:04:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.183.138 with HTTP; Mon, 26 Jun 2017 09:04:30 -0700 (PDT) In-Reply-To: <18210175522.20170626103248@mail.ru> References: <1599987034.20170623182536@mail.ru> <18210175522.20170626103248@mail.ru> From: Adrian Chadd Date: Mon, 26 Jun 2017 09:04:30 -0700 Message-ID: Subject: Re: using rc.subr only by root restriction To: Anthony Pankov Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Mon, 26 Jun 2017 16:15:12 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 16:04:33 -0000 On 26 June 2017 at 00:32, Anthony Pankov wrote: > Hello, > >> this was my fault. :) > > Did you mean that you've commited a patch which change the behavior? > >> There are some limits that you can set as a user. > >> I think this is a fine change; but I can't speak for the correctness >> of using rc.subr as a general library set for your own purposes. :0 > > At this time I don't think that my patch is a best solutions. > > First of all I don't see any explanation of ${name}_login_class in > rc.subr(8). Silently applying 'daemon' login class to all services > seems to be very surprising. I think there are people who modified 'daemon' > login class and get a weird result in their system. I know how > complex to investigate such things. It was supposed to be daemon class. That was the unclear part of it all. If it runs as part of startup, it'd get the daemon class. If you ran it using "service", you got whatever was in the users class. So your daemons would then get the "root" class, and get a LOT more file descriptors, etc. > 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. 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. -adrian