Re: Default group

On 10/17/2012 06:43 PM, Marc Deslauriers wrote: On 12-10-17 05:45 PM, John Moser wrote: On 10/17/2012 05:34 PM, Marc Deslauriers wrote: On 12-10-17 03:52 PM, John Moser wrote: First, he must find the sysadmin. The sysadmin must then put wriker in group jkirk. Also, ~jkirk must be group-

Re: Default group

On 12-10-17 05:45 PM, John Moser wrote: > > > On 10/17/2012 05:34 PM, Marc Deslauriers wrote: >> On 12-10-17 03:52 PM, John Moser wrote: >>> >>> First, he must find the sysadmin. The sysadmin must then put wriker >>> in group jkirk. Also, ~jkirk must be group-readable, as must any >>> files. >>

Re: Default group

On 10/17/2012 05:34 PM, Marc Deslauriers wrote: On 12-10-17 03:52 PM, John Moser wrote: First, he must find the sysadmin. The sysadmin must then put wriker in group jkirk. Also, ~jkirk must be group-readable, as must any files. In a default Ubuntu installation, jkirk's files are already a

Re: Default group

Doesn't look integrated into the default UI. Workable, but not quite intuitive. Things I'd prefer: - Shows the user and group ownership, instead of piling them is as just part of the ACL. Remember these have special meanings for SUID/SGID. - First three ACL entries are always Owner, Grou

Re: Default group

On 12-10-17 03:52 PM, John Moser wrote: > > Let's first assume we have three users: > > jkirk > ksingh > wriker > > Now, let's say any of these wants to give any of the others access to > his files in general (i.e. his $HOME). Let's for our example say > jkirk wants wriker to have access. > >

Re: Default group

It's called eiciel -- Matt Wheeler m...@funkyhat.org On 17 Oct 2012 21:15, "John Moser" wrote: > On Wed, Oct 17, 2012 at 3:52 PM, John Moser > wrote: > > First: that's why we need an interface that handles POSIX ACLs > > properly, long-overdue. > > > > It actually occurs to me that this is pro

Re: Default group

On Wed, Oct 17, 2012 at 3:52 PM, John Moser wrote: > First: that's why we need an interface that handles POSIX ACLs > properly, long-overdue. > It actually occurs to me that this is probably not just technically important, but important for planning purposes. That is, we can sit here arguing al

Re: Default group

First: that's why we need an interface that handles POSIX ACLs properly, long-overdue. Second, this is not simple. This is a recommendation to use shotgun approach to everything and leave gaping holes because it's convenient. I don't mean to say this is a critical 100% immediate security hole;

Re: Default group

John, Do you know KISS ? So ACL works well. But it's really more complicated to use than UGO and surely to understand who has which access to what. Trust me it can be really hard to get it with complex configurations. So I would say : wh

Re: pam-tmpdir promote to main?

On Wed, Oct 17, 2012 at 10:52 AM, Marc Deslauriers wrote: > > Now that we have symlink restrictions in Ubuntu, security issues with > using the /tmp directory are greatly reduced. > > Since Quantal now sets $XDG_RUNTIME_DIR, apps should use it or one of > the other $XDG_* locations to store tempor

Re: Default group

On Wed, Oct 17, 2012 at 10:44 AM, Marc Deslauriers wrote: > On 12-10-17 09:59 AM, John Moser wrote: >> I suggest all users should go into group 'users' as the default group, >> with $HOME default to 700 and in the group 'users'. A umask of 027 or >> the traditional 022 is still viable: the files

Re: pam-tmpdir promote to main?

On 12-10-17 10:19 AM, John Moser wrote: > Can we promote pam-tmpdir to main instead of universe for 13.04? It > seems to work pretty well now, and so I recommend activating it by > default early in the development cycle. Very early. Like first > change early: pam-tmpdir is part of the base syst

Re: Default group

> > To modify the groups a user is in, you must have administrative access You can use gpasswd -A to delegate group administration to a non-superuser. And the main reason of User Private Group (UPG) is that makes it easy to create directories for collaboration. 2012/10/17 John Moser > On Wed,

Re: Default group

On 12-10-17 09:59 AM, John Moser wrote: > I suggest all users should go into group 'users' as the default group, > with $HOME default to 700 and in the group 'users'. A umask of 027 or > the traditional 022 is still viable: the files in $HOME are not > visible because you cannot list the contents

pam-tmpdir promote to main?

Can we promote pam-tmpdir to main instead of universe for 13.04? It seems to work pretty well now, and so I recommend activating it by default early in the development cycle. Very early. Like first change early: pam-tmpdir is part of the base system default install. The rationale for this is p

Re: Default group

On Wed, Oct 17, 2012 at 10:05 AM, Jordon Bedwell wrote: > > The problem with this is how are you going to fix permissions on bad > software like Ruby Gems who do not reset permissions when packaging > and uploading to the public repository (because they claim this would > "violate security" even t

Re: Default group

On Wed, Oct 17, 2012 at 8:59 AM, John Moser wrote: > I suggest all users should go into group 'users' as the default group, > with $HOME default to 700 and in the group 'users'. A umask of 027 or > the traditional 022 is still viable: the files in $HOME are not > visible because you cannot list

Default group

Currently each Ubuntu user gets his own group, so: jsmith:jsmith lmanning:lmanning rpaul:rpaul and so on. I feel this is a lot of clutter for no benefit. First let's discuss the benefit. Since each user has his own group, the administrator can grant other users access to each others' files in

Re: DNS caching disabled for 12.10...still

On 12-10-17 04:34 AM, Daniel J Blueman wrote: > On 17 October 2012 16:18, Benjamin Kerensa wrote: >> On Wed, Oct 17, 2012 at 12:59 AM, Jordon Bedwell >>> On Tue, Oct 16, 2012 at 3:27 PM, Colin Watson wrote: For example, it allows changing nameservers reliably without having to restart

Re: DNS caching disabled for 12.10...still

On 17 October 2012 16:18, Benjamin Kerensa wrote: > On Wed, Oct 17, 2012 at 12:59 AM, Jordon Bedwell >> On Tue, Oct 16, 2012 at 3:27 PM, Colin Watson wrote: >> > For example, it allows changing nameservers reliably without having to >> > restart applications, and allows us to dispatch DNS querie

Re: could you add this feature or discuss it at 13.04 Developer Summit?

Brian, Continuing to search, I found the exact app you were searching for and the last version is pretty recent (feb 2012) : http://sourceforge.net/projects/leopardflower/files/ It logs access and can restrict app access to the network. But I never tryied it. Regards, Nicolas 2012/10/17 Ma Xia

Re: DNS caching disabled for 12.10...still

On Wed, Oct 17, 2012 at 12:59 AM, Jordon Bedwell wrote: > On Tue, Oct 16, 2012 at 3:27 PM, Colin Watson wrote: > > For example, it allows changing nameservers reliably without having to > > restart applications, and allows us to dispatch DNS queries on different > > links depending on the domain

Re: DNS caching disabled for 12.10...still

On Tue, Oct 16, 2012 at 3:27 PM, Colin Watson wrote: > For example, it allows changing nameservers reliably without having to > restart applications, and allows us to dispatch DNS queries on different > links depending on the domain (consider VPNs). Could there not be an option inside of NM that

Re: DNS caching disabled for 12.10...still

On Sun, Oct 07, 2012 at 01:13:14PM -1000, Paul Graydon wrote: > If DNS caching is being disabled in dnsmasq, what value is being had > from using dnsmasq by default with network connections? Seems like > it just presents another potential failure point. For example, it allows changing nameservers