From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id B60BA138CC5 for ; Mon, 23 Mar 2015 11:28:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 50BC2E086A; Mon, 23 Mar 2015 11:28:17 +0000 (UTC) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 54F00E0824 for ; Mon, 23 Mar 2015 11:28:16 +0000 (UTC) Received: by iedm5 with SMTP id m5so32908330ied.3 for ; Mon, 23 Mar 2015 04:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=wrqjPMrzW6fSd3NQN5YKj7anFXMko/BGwgPLUIJi2Zs=; b=lP2BkZ8NFig5jKI0rm9O9KgVsQaVyMdJwgdeQ6bkSjfJ7uY6nuojTSk0M2Q0ErZwre SiAX5ndcBKbMi9ES5chJ0m3biXSeeYFj625t+kQ/XWmZ0BJA/sm1+SzJMVe93KAzXwqu UmTggB8WUly5XPcnA5YfLo9JqPWiA3lnKszyV/ERLoD6EOWTZ/l3ZmWKkhxDNpX1G/p0 Zy+cM0aJ0xuCcfP19sQclUyP/TCYgzmgqx6slqBSWXHzUDkjy0KdoVgAf0jakfrwSMFo 5mz3mE3zxXit/L1Ayjp7WbzMqD+G5FXvzh+By0m0JyZxe9gfvt9iT/FFCDpjNWfANZs1 CTGw== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.50.25.166 with SMTP id d6mr13530503igg.41.1427110095557; Mon, 23 Mar 2015 04:28:15 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.107.135.78 with HTTP; Mon, 23 Mar 2015 04:28:15 -0700 (PDT) In-Reply-To: <23787818.Bd5keXIqRP@wstn> References: <20150321152656.a82a84b3e8a32c8b68554548@gmail.com> <2098241.ygyfAjpUPx@wstn> <23787818.Bd5keXIqRP@wstn> Date: Mon, 23 Mar 2015 07:28:15 -0400 X-Google-Sender-Auth: KyYQVcT6Erybkv6ygtuPU0jQCCk Message-ID: Subject: Re: [gentoo-user] How to poweroff the system from user? From: Rich Freeman To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: eaa0d0e5-677c-4b77-8494-5c5fa1e9f1c5 X-Archives-Hash: 51d324da599d740be222506b8c26cd09 On Mon, Mar 23, 2015 at 5:46 AM, Peter Humphrey wrote: > > The remaining question is: why is the user not allowed to halt it? > Keep in mind there are many ways that a unix-like OS can be used. It could be running on a laptop, or it could be running on a multi-user system where 50 people are logged in at any given time. In the former case you want a desktop-like experience where the user can just hit the shutdown button, and in the latter case you don't want users powering off the server which might be 4 states away. The old solution to this was just having the system owner run sudo poweroff. Then desktop environments came up with a way to allow a logged in user to send a command back to the display manager (which runs as root) to tell it to shut down the system, and made whether that is allowed configurable. The most recent evolution of this is consolekit/logind, which distinguishes users logged in at the system console from those logged in remotely and grants the authority to shutdown the system if you're local. This approach also does things like assign permissions to audio devices as well, so that only the person sitting at the console can spy on the console using the microphone and you don't need to control this manually using an audio group. The other trend is for unprivileged processes access privileged functions via dbus, controlled by polkit. This allows granular control over what users/groups/etc can run what functions, potentially based on whether they're at a local console or not. You can even control that particular functions require a root password or for the user to re-enter their password. This puts all the policy rules in /etc and reduces the amount of per-application configuration. It is a bit like sudoers, but with more fine-grained control and without getting into hard-coding command lines (which can be a bit clumsy). The traditional downside to this approach has been the need to run dbus, but this is moving into the kernel and the intent is to encourage processes to utilize it as the main IPC mechanism. The end goal is to try to get reasonable default behavior without requiring either desktop or server administrators to have to do much, or to have to designate a distro as being primarily desktop vs server in nature. On a server nobody is logged in via the console, so you get restricted privileges by default. On a desktop the main user is logged in via the console and can use their webcam+mic, but others who might be allowed to login cannot remotely connect over the network and spy on the same. However, all of this is configurable - you can stick rules in /etc which change these behaviors. -- Rich