On Wed, Mar 04, 2009 at 06:12:54PM +0100, Josselin Mouette wrote:
Using things like pam_console or pam_group should not become our default
policy, unless we at least ensure /home, /var and /tmp are mounted
nosuid – and it would be better with the ability to revoke the
permissions on the open devi
On Wed, Mar 04, 2009 at 06:12:54PM +0100, Josselin Mouette wrote:
> Le mercredi 04 mars 2009 à 17:55 +0100, Petter Reinholdtsen a écrit :
> > Personally, I believe adding users to these groups at install time is
> > the wrong approach, and believe the only scalable way to handle this
> > is with po
Josselin Mouette writes:
[...]
> There is ongoing work in the kernel to finally add session support in
> it, so maybe something good will come out of it, but otherwise this is
> still the same mess.
[...]
Any pointer for this discussion?
--
O T A V I OS A L V A D O R
---
Le mercredi 04 mars 2009 à 17:55 +0100, Petter Reinholdtsen a écrit :
> Personally, I believe adding users to these groups at install time is
> the wrong approach, and believe the only scalable way to handle this
> is with policykit like features. Then the group membership is handled
> dynamically
[Christian Perrier]
>> I did several subsequent installs and my user never ended
>> up in powerdev (nor netdev for that matter). It's my belief
>> (yet to check d-i code to confirm) that the user gets added
>> to powerdev if you select the desktop task: for each of my
>
> Not really. It *should* b
> In shortthe first created user *should* be in powerdev. If it is
> notthen there's a bug in user-setup (or somewhere else...).
The powerdev group only exists if hal is installed, which is only the
case if one of the desktop tasks is installed. If the group does not
exist, the initial use
Quoting Jon Dowland (jon+debian-de...@alcopop.org):
> I did several subsequent installs and my user never ended
> up in powerdev (nor netdev for that matter). It's my belief
> (yet to check d-i code to confirm) that the user gets added
> to powerdev if you select the desktop task: for each of my
On Thu, 2009-02-26 at 13:01 +, Ben Hutchings wrote:
> On Thu, 2009-02-26 at 08:31 +0100, Peter Palfrader wrote:
> > This is of course broken. It breaks granting console users access
> > to the netdev or powerdev groups through pam_groups, which is really
> > really annoying when you get your u
On Thu, 2009-02-26 at 08:31 +0100, Peter Palfrader wrote:
> On Wed, 25 Feb 2009, Roger Leigh wrote:
>
> > HAL is just querying the group database directly. Any process can of
> > course do this. But it's asking a different question, namely:
> > what groups is this user a member of in the group d
On Wed, 25 Feb 2009, Roger Leigh wrote:
> HAL is just querying the group database directly. Any process can of
> course do this. But it's asking a different question, namely:
> what groups is this user a member of in the group database.
This is of course broken. It breaks granting console user
On Tue, Feb 24, 2009 at 02:11:36PM +, Jon Dowland wrote:
> Finally can anyone with a deeper insight of the issues
> explain whether or not the frustrating "existing logins
> don't inherit new groups" behaviour is fixable, or is that
> deeply rooted in UNIX tradition?
The limitation is due to
On Tue, Feb 24, 2009 at 6:11 AM, Jon Dowland
wrote:
> Hi folks,
>
> I filed a bug against gnome-power-manager a little while
> ago because I could not suspend. It turned out my user was
> not in the powerdev group.
Hi, there are already some bugs open about this, because it's
obviously an annoyin
Hi folks,
I filed a bug against gnome-power-manager a little while
ago because I could not suspend. It turned out my user was
not in the powerdev group.
It was Joss' initial belief that the non-root user that you
create in d-i is added to a fixed set of groups, including
powerdev. For the remaind
13 matches
Mail list logo
