On Fri, Oct 29, 2010 at 10:12 PM, Brynet wrote:
>
> I believe the real problem here is that you're allowing users on your
> systems that are incapable of properly setting the group/world
> permissions of their home directories.
My employer lets a variety of people on their systems - they just wan
On Fri, Oct 29, 2010 at 10:12 PM, Brynet wrote:
> Daniel wrote:
>> Same here. Really, I'm surprised that anyone is using the 'users'
>> group at all these days, especially on OpenBSD. If all users are in
>> the same group, group permissions are no different from world
>> permissions.
>
> I belie
* Brynet [2010-10-30 11:12]:
> All I was trying to communicate is that the exposure of a users home
> directory is something that must be dealt with by system administrators
> or preferably by the individual users themselves.
[ ] you grok "sane defaults"
--
Henning Brauer, h...@bsws.de, henn...
Paul de Weerd wrote:
> Welcome, to the real world. Users are incapable of just about
> anything. Except for fucking things up, they're extremely good at
> that. Live with it.
So wait, are you for or against creating lone groups for individual users?
All I was trying to communicate is that the
On Sat, Oct 30, 2010 at 01:12:54AM -0400, Brynet wrote:
| Daniel wrote:
| > Same here. Really, I'm surprised that anyone is using the 'users'
| > group at all these days, especially on OpenBSD. If all users are in
| > the same group, group permissions are no different from world
| > permissions.
Daniel wrote:
> Same here. Really, I'm surprised that anyone is using the 'users'
> group at all these days, especially on OpenBSD. If all users are in
> the same group, group permissions are no different from world
> permissions.
I believe the real problem here is that you're allowing users on
On Fri, Oct 29, 2010 at 11:25 AM, Henning Brauer
wrote:
> * Philip Guenther [2010-10-29 19:48]:
>
>> Group-per-user setups solve this by letting people safely have a umask
>> of 007 or 002. When they do work in a directory whose group is a
>> secondary group, the resulting files are (and stay) w
* Philip Guenther [2010-10-29 19:48]:
> Back in my pure sysadmin days, I found that when users all (or almost
> all) share a default group like "users", then it isn't easy enough for
> normal users to leverage other groups for shared access to files and
> directories. Because the default group is
On Fri, Oct 29, 2010 at 9:40 AM, Theo de Raadt
wrote:
>> On Fri, Oct 29, 2010 at 02:29:50PM +0200, Ingo Schwarze wrote:
...
>> This topic came up last year as well, including the same useradd/adduser
>> confusion:
>> http://kerneltrap.org/mailarchive/openbsd-tech/2009/5/8/5660874
>>
>> "useradd re
On Fri, Oct 29, 2010 at 10:52:46AM +0200, Tobias Ulmer wrote:
> The installer defaults to creating accounts with group "users", adduser
> creates a group for each user. Sync the two.
> Takes effect only if /etc/addusers.conf is regenerated, ie. new
> installations.
This should lead to at least the
> On Fri, Oct 29, 2010 at 02:29:50PM +0200, Ingo Schwarze wrote:
> > Hi Tobias,
> >
> > i'm not sure as i don't use tools like adduser(8) and useradd(8),
> > and i doubt they are widely used among developers anyway. I think
> > they are around mostly because some people are used to them from
> >
On Fri, 29 Oct 2010 15:02:05 +0200
Tobias Ulmer wrote:
> "useradd really does that? A new group for every user? I think that
> is stupid behaviour."
>
> So, I stand by my patch,
> Tobias
Personally I prefer the unique group by default behaviour, but I also
don't have a problem with double che
On Fri, Oct 29, 2010 at 02:29:50PM +0200, Ingo Schwarze wrote:
> Hi Tobias,
>
> i'm not sure as i don't use tools like adduser(8) and useradd(8),
> and i doubt they are widely used among developers anyway. I think
> they are around mostly because some people are used to them from
> other systems.
Hi Tobias,
i'm not sure as i don't use tools like adduser(8) and useradd(8),
and i doubt they are widely used among developers anyway. I think
they are around mostly because some people are used to them from
other systems.
So, gratuitously changing the defaults is not necessarily a wise move.
As
The installer defaults to creating accounts with group "users", adduser
creates a group for each user. Sync the two.
Takes effect only if /etc/addusers.conf is regenerated, ie. new
installations.
Index: adduser.perl
===
RCS file: /srv
15 matches
Mail list logo
