Re: DNS caching disabled for 12.10...still

[Colin Watson]

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 reliably without having to
restart applications, and allows us to dispatch DNS queries on different
links depending on the domain (consider VPNs).

-- 
Colin Watson   [cjwat...@ubuntu.com]

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: DNS caching disabled for 12.10...still

[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 queries on different
> links depending on the domain (consider VPNs).

Could there not be an option inside of NM that enables and disables
DNS caching (or even on the right click menu for example, where we can
easily disable networks on our laptops.) Maybe it could even be
expanded to do except so you can disable the caching per interface
too.

I actually like that idea, I wish I had time to look into helping
implement something like this.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: DNS caching disabled for 12.10...still

[Benjamin Kerensa]

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 (consider VPNs).
>
> Could there not be an option inside of NM that enables and disables
> DNS caching (or even on the right click menu for example, where we can
> easily disable networks on our laptops.) Maybe it could even be
> expanded to do except so you can disable the caching per interface
> too.
>

There could be an option but if I remember correctly we sync
network-manager from upstream so a change like that would likely be best
made upstream.

Correct me if I'm wrong someone?


>
> I actually like that idea, I wish I had time to look into helping
> implement something like this.
>
>

-- 
*Benjamin Kerensa*
*http://benjaminkerensa.com*
*"I am what I am because of who we all are" - Ubuntu*
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

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

[Nicolas Michel]

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 Xiaojun 

> On Wed, Oct 17, 2012 at 1:23 AM, Nicolas Michel
>  wrote:
> > In consequence, all applications that you install from the Ubuntu
> Software
> > center are considered "safe" by the distribution maintainers because
> they or
> > others members of the open-source community already reviewed the source
> > code. This is why you always should prefer installing app from the ubuntu
> > software center than from the net directly except if you know what you're
> > doing.
> I think Ubuntu software center also features non-open source stuff now.
> http://developer.ubuntu.com/publish/
> The trust model is more like Apple's app store now.
> The developers of apps may be considered as untrusted.
> But the apps have gone through the review a (hopefully) trusted company.
>
> > Other argument against the app firewall level with popus: let the user
> the
> > possibility to easily configure the security of its computer is only
> usefull
> > when the user knows what he's really doing and all consequences. Most
> people
> > will click on "yes" on every popup that appears without asking themselves
> > the consequences of that click.
> > Final argument against : I hate popups :)
> All true, so the origin poster need a logger.
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>



-- 
Nicolas MICHEL
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: DNS caching disabled for 12.10...still

[Daniel J Blueman]

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 queries on different
>> > links depending on the domain (consider VPNs).
>>
>> Could there not be an option inside of NM that enables and disables
>> DNS caching (or even on the right click menu for example, where we can
>> easily disable networks on our laptops.) Maybe it could even be
>> expanded to do except so you can disable the caching per interface
>> too.

> There could be an option but if I remember correctly we sync network-manager
> from upstream so a change like that would likely be best made upstream.

Above all, the way to address this is to share the reasoning of why
DNS caching was disabled with the upstream NetworkManager and dnsmasq
authors.

At least there's a chance to document, ratify and address any issues
openly, but alas this did not occur.

Daniel
-- 
Daniel J Blueman

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: DNS caching disabled for 12.10...still

[Marc Deslauriers]

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 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 enables and disables
>>> DNS caching (or even on the right click menu for example, where we can
>>> easily disable networks on our laptops.) Maybe it could even be
>>> expanded to do except so you can disable the caching per interface
>>> too.
> 
>> There could be an option but if I remember correctly we sync network-manager
>> from upstream so a change like that would likely be best made upstream.
> 
> Above all, the way to address this is to share the reasoning of why
> DNS caching was disabled with the upstream NetworkManager and dnsmasq
> authors.
> 

DNS caching was disabled for security reasons, among others, mainly
because using the same cache for all users allows one user to know where
other users have been by probing the cache, and because it is trivial to
poison the cache when you're a local user and can inspect information
available locally such as source ports. In a multi-user system, caching
needs to be done with a separate cache per user.

Marc.


-- 
Marc Deslauriers
Ubuntu Security Engineer | http://www.ubuntu.com/
Canonical Ltd.   | http://www.canonical.com/

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Default group

[John Moser]

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 a fine-grained manner by adding
them to other users' groups.  This seems useful, but consider:

 - To modify the groups a user is in, you must have administrative access
 - As long as you're modifying users anyway, you're in a position to
create a group and add both users to it
 - This is better accomplished with POSIX ACLs, which users can
control on files they own

That third one, by the way, suggests that we should have a Windows NT
style permissions tab in Nautilus' file properties such that you can
add a user and alter their permissions.  UNIX permissions allow you to
set Owner, Group, Owner access, Group access, Other access; POSIX ACLs
allow additional Users and Groups to be added with their own
permissions as well.  Thus:

Creator/Owner:  [User]
Group:  [Group]
Permissions:
::Creator/Owner:  rwx
::Group:  ---
::Everyone:  ---
::group=developers:  rwx
::group=managers:  r-x

etc



The above suggests to me that any such benefit from giving users
individual groups is quickly mitigated because either A) the users are
all administrators, so sharing versus isolating files is wholly
imaginary; or B) giving fine-grained access via group membership
requires administrator mediation.

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 of $HOME (not readable)
or change into it to access the files within (not executable).  A user
can grant permissions to other users to access his files simply by
making the directory readable by them--by 'users' or others (thus
everyone) or by fine-grained POSIX ACLs selecting for individual users
and groups.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Default group

[Jordon Bedwell]

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 the contents of $HOME (not readable)
> or change into it to access the files within (not executable).  A user
> can grant permissions to other users to access his files simply by
> making the directory readable by them--by 'users' or others (thus
> everyone) or by fine-grained POSIX ACLs selecting for individual users
> and groups.

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 though it comes from a public repo like the
Debian repo and having public read and execute on a public gem from a
public place is "bad".) This has a huge impact as a default permission
for not just examples like Ruby gems but other software do not reset
when packaging, making it more cumbersome to package software and
making it so now work around's are the rule and not the exception.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Default group

[John Moser]

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 though it comes from a public repo like the
> Debian repo and having public read and execute on a public gem from a
> public place is "bad".) This has a huge impact as a default permission
> for not just examples like Ruby gems but other software do not reset
> when packaging, making it more cumbersome to package software and
> making it so now work around's are the rule and not the exception.

Explain the problem more.  The directory the user is in would be owned
by $USER:users instead of $USER:$USER.  The only difference, then, is
instead of your stuff being owned by jordon:jordon it's owned by
jordon:users.

What you're saying here is... I don't know what you're saying.
Permissions are currently $USER:users by default with umask=022 and
$HOME permissions of 755 which means every file is created as:

drwxr-xr-x jordan:jordan /home/jordan
drwxr-xr-x jordan:jordan /home/jordan/somedir
-rwxr--r-- jordan:jordan /home/jordan/somefile

What I'm suggesting is either umask=022 with a shared 'users' group
and a default $HOME permission of 700, so

drwx-- jordan:users /home/jordan
drwxr-xr-x jordan:users /home/jordan/somedir
-rwxr--r-- jordan:users /home/jordan/somefile

In which case if you give the 'users' group or (via extended ACL) any
other group or person read/execute on /home/jordan they can read
everything:  they're in 'users' and thus have access to your files,
just before they couldn't actually reach the inode.  If you give
'others' read/execute on /home/jordan then everyone on the system can
see inside your $HOME, as is the case now.


...OR--more risky--a default umask=027 with a shared 'users' group and
a default $HOME permission of 700, so

drwx-- jordan:users /home/jordan
drwxr-x--- jordan:users /home/jordan/somedir
drwxr- jordan:users /home/jordan/somefile

and security is increased, nominally, but honestly not much.  The
security boost here is files created in shared directories or
hardlinks created won't let anyone and everyone read those files; the
truth of the matter is that shouldn't happen, and stuff done in /tmp
is usually ... temporary, and aware of the security implications.
More restrictive you could umask=077, but same deal, and then if you
want to give anyone access to your files you have to change
permissions the whole way down (which opens up the user to mistakes
like chmod -R on $HOME and exposing their SSH keys).


How does putting everyone in the same group and changing $HOME to 0700
do what you said?

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

pam-tmpdir promote to main?

[John Moser]

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 pam-tmpdir makes changes to $TMP and $TMPDIR
which affect application behavior.  Non-conforming applications will
dump their temp files into /tmp anyway; conforming applications using
$TMP or $TMPDIR will put them in a user-specific directory.  SOME
applications may break--they shouldn't, but GDM broke in 2004 so I
could see things breaking.

Applications ceasing to function is what I'm interested in.  Anything
that's built and tested that fails to run properly under pam-tmpdir.

pam-tmpdir creates a root-owned directory /tmp/users with permissions
o=--x.  Upon log-on, pam creates a directory /tmp/users/$UID/ owned by
the user and with permissions 700. That becomes $TMP and $TMPDIR, and
so most applications put their temporary files there.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Default group

[Marc Deslauriers]

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 of $HOME (not readable)
> or change into it to access the files within (not executable).  A user
> can grant permissions to other users to access his files simply by
> making the directory readable by them--by 'users' or others (thus
> everyone) or by fine-grained POSIX ACLs selecting for individual users
> and groups.
> 

We want users to be able to share files with other users. Having $HOME
be 700 defeats that purpose. See:

https://wiki.ubuntu.com/SecurityTeam/Policies#Permissive_Home_Directory_Access

Also, one of the reasons for using User Private Groups, is to be able to
create directories that are used by multiple users, by setting the
setgid on the directory. With a default umask of 022, users need to
manually set group permissions each time they create a file.

Marc.


-- 
Marc Deslauriers
Ubuntu Security Engineer | http://www.ubuntu.com/
Canonical Ltd.   | http://www.canonical.com/

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Default group

[Alberto Gonzalez]

>
> 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, 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 though it comes from a public repo like the
> > Debian repo and having public read and execute on a public gem from a
> > public place is "bad".) This has a huge impact as a default permission
> > for not just examples like Ruby gems but other software do not reset
> > when packaging, making it more cumbersome to package software and
> > making it so now work around's are the rule and not the exception.
>
> Explain the problem more.  The directory the user is in would be owned
> by $USER:users instead of $USER:$USER.  The only difference, then, is
> instead of your stuff being owned by jordon:jordon it's owned by
> jordon:users.
>
> What you're saying here is... I don't know what you're saying.
> Permissions are currently $USER:users by default with umask=022 and
> $HOME permissions of 755 which means every file is created as:
>
> drwxr-xr-x jordan:jordan /home/jordan
> drwxr-xr-x jordan:jordan /home/jordan/somedir
> -rwxr--r-- jordan:jordan /home/jordan/somefile
>
> What I'm suggesting is either umask=022 with a shared 'users' group
> and a default $HOME permission of 700, so
>
> drwx-- jordan:users /home/jordan
> drwxr-xr-x jordan:users /home/jordan/somedir
> -rwxr--r-- jordan:users /home/jordan/somefile
>
> In which case if you give the 'users' group or (via extended ACL) any
> other group or person read/execute on /home/jordan they can read
> everything:  they're in 'users' and thus have access to your files,
> just before they couldn't actually reach the inode.  If you give
> 'others' read/execute on /home/jordan then everyone on the system can
> see inside your $HOME, as is the case now.
>
>
> ...OR--more risky--a default umask=027 with a shared 'users' group and
> a default $HOME permission of 700, so
>
> drwx-- jordan:users /home/jordan
> drwxr-x--- jordan:users /home/jordan/somedir
> drwxr- jordan:users /home/jordan/somefile
>
> and security is increased, nominally, but honestly not much.  The
> security boost here is files created in shared directories or
> hardlinks created won't let anyone and everyone read those files; the
> truth of the matter is that shouldn't happen, and stuff done in /tmp
> is usually ... temporary, and aware of the security implications.
> More restrictive you could umask=077, but same deal, and then if you
> want to give anyone access to your files you have to change
> permissions the whole way down (which opens up the user to mistakes
> like chmod -R on $HOME and exposing their SSH keys).
>
>
> How does putting everyone in the same group and changing $HOME to 0700
> do what you said?
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>



-- 
-
The greatest harm can result from the best intentions
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: pam-tmpdir promote to main?

[Marc Deslauriers]

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 system default install.
> 
> The rationale for this is pam-tmpdir makes changes to $TMP and $TMPDIR
> which affect application behavior.  Non-conforming applications will
> dump their temp files into /tmp anyway; conforming applications using
> $TMP or $TMPDIR will put them in a user-specific directory.  SOME
> applications may break--they shouldn't, but GDM broke in 2004 so I
> could see things breaking.
> 
> Applications ceasing to function is what I'm interested in.  Anything
> that's built and tested that fails to run properly under pam-tmpdir.
> 
> pam-tmpdir creates a root-owned directory /tmp/users with permissions
> o=--x.  Upon log-on, pam creates a directory /tmp/users/$UID/ owned by
> the user and with permissions 700. That becomes $TMP and $TMPDIR, and
> so most applications put their temporary files there.
> 

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 temporary user data. If use of /tmp
is still necessary, apps should simply assign appropriate permissions to
the files they create in /tmp.

Please file bugs on any app that doesn't currently do this properly.

Marc.


-- 
Marc Deslauriers
Ubuntu Security Engineer | http://www.ubuntu.com/
Canonical Ltd.   | http://www.canonical.com/

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Default group

[John Moser]

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 in $HOME are not
>> visible because you cannot list the contents of $HOME (not readable)
>> or change into it to access the files within (not executable).  A user
>> can grant permissions to other users to access his files simply by
>> making the directory readable by them--by 'users' or others (thus
>> everyone) or by fine-grained POSIX ACLs selecting for individual users
>> and groups.
>>
>
> We want users to be able to share files with other users. Having $HOME
> be 700 defeats that purpose. See:
>
> https://wiki.ubuntu.com/SecurityTeam/Policies#Permissive_Home_Directory_Access
>

Which, as I said, is accomplished by adding the user or an appropriate
group to the Extended ACL of $HOME, as the umask is still permissive
and the files are all owned by a common user group.  It can also be
blanket accomplished by adding read access to group or others on
$HOME, which would return the system to effectively as it is now.

> Also, one of the reasons for using User Private Groups, is to be able to
> create directories that are used by multiple users, by setting the
> setgid on the directory. With a default umask of 022, users need to
> manually set group permissions each time they create a file.
>

Setting setgid on the directory to allow multiple users to add files
to it still requires that the users be in the group or that the
directory be world-writable. The proper way to accomplish this is,
again, to place the directory into the shared 'users' group and grant
individual user or group access via ACLs, rather than a shotgun
approach by which either the directory is either world-writable or the
users have to be put into some other user's group and then suddenly
have blanket access to that user's files unless he tightens down
permissions on his $HOME.

setgid would also do ... just about nothing, since without setUID on
the directory the file's permissions are still g-w.  Although some
Googling is telling me that Ubuntu changed the default umask to 002
back in Oneric, so apparently yeah this works, caveat above paragraph.

In short, the current method is a lot of "this works..." with a lot of
unintended consequences.


> Marc.
>
>
> --
> Marc Deslauriers
> Ubuntu Security Engineer | http://www.ubuntu.com/
> Canonical Ltd.   | http://www.canonical.com/
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: pam-tmpdir promote to main?

[John Moser]

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 temporary user data. If use of /tmp
> is still necessary, apps should simply assign appropriate permissions to
> the files they create in /tmp.

I'm more concerned with keeping the contents of /tmp private.  When I
filed bugs for Thunderbird and Firefox years ago (which never got
fixed) I pointed out things like site designations, client names, and
(amusingly) pornography being leaked through /tmp.  Which has got to
be great when you're 15 and peeking at /tmp to see what kinds of
flicks your dad's been downloading, though now everything streams in
browser.

Well, except torrent names, which are spewed all over the place, and
stay there until reboot.

>
> Please file bugs on any app that doesn't currently do this properly.
>
> Marc.
>
>
> --
> Marc Deslauriers
> Ubuntu Security Engineer | http://www.ubuntu.com/
> Canonical Ltd.   | http://www.canonical.com/
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Default group

[Nicolas Michel]

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 : why use a complex solution for a simple need?

Regards,
Nicolas

2012/10/17 John Moser 

> 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 in $HOME are not
> >> visible because you cannot list the contents of $HOME (not readable)
> >> or change into it to access the files within (not executable).  A user
> >> can grant permissions to other users to access his files simply by
> >> making the directory readable by them--by 'users' or others (thus
> >> everyone) or by fine-grained POSIX ACLs selecting for individual users
> >> and groups.
> >>
> >
> > We want users to be able to share files with other users. Having $HOME
> > be 700 defeats that purpose. See:
> >
> >
> https://wiki.ubuntu.com/SecurityTeam/Policies#Permissive_Home_Directory_Access
> >
>
> Which, as I said, is accomplished by adding the user or an appropriate
> group to the Extended ACL of $HOME, as the umask is still permissive
> and the files are all owned by a common user group.  It can also be
> blanket accomplished by adding read access to group or others on
> $HOME, which would return the system to effectively as it is now.
>
> > Also, one of the reasons for using User Private Groups, is to be able to
> > create directories that are used by multiple users, by setting the
> > setgid on the directory. With a default umask of 022, users need to
> > manually set group permissions each time they create a file.
> >
>
> Setting setgid on the directory to allow multiple users to add files
> to it still requires that the users be in the group or that the
> directory be world-writable. The proper way to accomplish this is,
> again, to place the directory into the shared 'users' group and grant
> individual user or group access via ACLs, rather than a shotgun
> approach by which either the directory is either world-writable or the
> users have to be put into some other user's group and then suddenly
> have blanket access to that user's files unless he tightens down
> permissions on his $HOME.
>
> setgid would also do ... just about nothing, since without setUID on
> the directory the file's permissions are still g-w.  Although some
> Googling is telling me that Ubuntu changed the default umask to 002
> back in Oneric, so apparently yeah this works, caveat above paragraph.
>
> In short, the current method is a lot of "this works..." with a lot of
> unintended consequences.
>
>
> > Marc.
> >
> >
> > --
> > Marc Deslauriers
> > Ubuntu Security Engineer | http://www.ubuntu.com/
> > Canonical Ltd.   | http://www.canonical.com/
> >
> > --
> > Ubuntu-devel-discuss mailing list
> > Ubuntu-devel-discuss@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>



-- 
Nicolas MICHEL
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Default group

[John Moser]

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;
I mean that trying to carefully, craftily use the current scheme is
very complex.

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.

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.

To do this without a sysadmin, the user must be sysadmin.  Either none
or one of these users can do it all; or all of them can and then we're
not dealing with any kind of document security.

With POSIX ACL instead AND AN INTERFACE FOR IT, jkirk simply
right-clicks on his Home directory in Nautilus (Konqueror Thunar etc),
hits Permissions, Add, puts in 'wriker' with 'read, access files
inside directory'.  Since his files are all read-write by group
(umask=002) instead of just readable (umask=022), this makes all his
files writable by wriker, of course.  That's not the point here,
HOWEVER it is a concern.

Notice this is simple, and the user can do it themselves.



Someone raised shared directories and SGID.  When we get to SGID we've
stepped slightly outside simple, but I'll allow it.

Let's say now jkirk wants to share specific files with wriker, and
specific other files with ksingh.  Let's tackle ksingh first.

jkirk could put a directory in a shared location, with SGID,
accessible by jkirk, and have the sysadmin give ksingh the jkirk
group.  This would, of course, also allow ksingh into anything else
accessible by jkirk's group--so if his home directory is open, or if
he has a file shared with wriker by putting wriker in the jkirk group,
those files are also accessible by ksingh as a matter of course.

Repeat:  those OTHER files are also accessible by ksingh as a matter of course.

Instead, ksingh could have jkirk put in the ksingh group; this creates
the same problem for ksingh.

Next of course jkirk tries to create a shared directory to share some
files with wriker, but of course that makes things complex.  Maybe
wriker does it, but then he shares with ksingh, which means wriker has
the same problem of jkirk getting files he wants to only share with
ksingh, or jkirk must accept the problem of sharing files with ksingh
when he only wants those files to go to wriker (and with wriker when
he wants those files only to go to ksingh).

Then, everybody gives up and just uses e-mail to send files back and forth.

Instead, jkirk creates a directory to share with ksingh.  The
directory is mode 700, owned by jkirk, and in the group 'users', and
with the SGID bit set (so not mode 700, more mode 02700?  I forget
what's SUID, SGID, and sticky, ok?).  He right clicks on it, hits
Properties, Permissions, adds ksingh with rwx (remember X on
directories is "access files inside").  When jkirk or ksingh creates
files inside, they are read/write by group and automatically in the
group 'users', so jkirk and ksingh can access all files in the
directory.

Then, jkirk creates a directory to share with wriker.  He does the
same, except adds wriker to the access list.  Same thing, but ksingh
can't access any of the files in it because the directory is 700 and
so he can't list the files and, even if he could, he can't actually
traverse the directory to access the files.  Similarly, wriker can't
access the directory shared by ksingh.

And, of course, jkirk has been granted no additional permissions.
Still, wriker or ksingh could do the same to give jkirk or each other
shared directories to access.  It's a simple create directory, right
click, add access, and there's no implications of other access by
other people because of other stuff you did with other directories at
other times.  Also, the system administrator isn't involved.



That's called "keeping it simple."  What's simple with the current
design is nobody has to develop a user interface for managing POSIX
ACLs--which would of course involve work, and open source developers
are a limited resource because they only work on things they actually
care about.

What's simple about the proposed design is the end user doesn't have
to change what group people are in or do complicated association
graphs and jump through hoops to get the simplest sharing between two
users to not open up other files they don't intend to share.

Also important is, with the current design, if you share with more
than one or two other users or you have overlapping access you WILL
wind up giving excessive access to someone.  For example, one user
creates a shared directory with two users, and another shared
directory with only one of those two users.  You can'

Re: Default group

[John Moser]

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 all day about theoretical use cases, but everybody is
going to have differing opinions that lean in odd directions until
certain things are fixed.  Or in short, as long as POSIX ACLs require
a scout badge in command line comfort, discussing how to leverage
POSIX ACLs is pointless because people don't want to think two steps
out.

Let's see if we can get anything agreeable on that.  It'll probably
look strikingly like Windows' Security tab, except without supplying
Allow/Deny, fine grained special permissions (which don't exist), or
having all the Windows main permissions.  So, it'll look like the only
thing that makes sense in general, and specifically for Unix.  That
is, a few rows of controls for Owner, Group, and then a list box of
permissions with one row with three checkboxes per row for each user
(Owner, Group, Everyone, individual users/groups).

Can we get that?

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Default group

[Matt Wheeler]

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 probably not just technically
> important, but important for planning purposes.  That is, we can sit
> here arguing all day about theoretical use cases, but everybody is
> going to have differing opinions that lean in odd directions until
> certain things are fixed.  Or in short, as long as POSIX ACLs require
> a scout badge in command line comfort, discussing how to leverage
> POSIX ACLs is pointless because people don't want to think two steps
> out.
>
> Let's see if we can get anything agreeable on that.  It'll probably
> look strikingly like Windows' Security tab, except without supplying
> Allow/Deny, fine grained special permissions (which don't exist), or
> having all the Windows main permissions.  So, it'll look like the only
> thing that makes sense in general, and specifically for Unix.  That
> is, a few rows of controls for Owner, Group, and then a list box of
> permissions with one row with three checkboxes per row for each user
> (Owner, Group, Everyone, individual users/groups).
>
> Can we get that?
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Default group

[Marc Deslauriers]

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.
> 
> 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 accessible
to other users.

> 
> To do this without a sysadmin, the user must be sysadmin.  Either none
> or one of these users can do it all; or all of them can and then we're
> not dealing with any kind of document security.
> 
> With POSIX ACL instead AND AN INTERFACE FOR IT, jkirk simply
> right-clicks on his Home directory in Nautilus (Konqueror Thunar etc),
> hits Permissions, Add, puts in 'wriker' with 'read, access files
> inside directory'.  Since his files are all read-write by group
> (umask=002) instead of just readable (umask=022), this makes all his
> files writable by wriker, of course.  That's not the point here,
> HOWEVER it is a concern.
> 
> Notice this is simple, and the user can do it themselves.
>

A user can't change permissions on his $HOME by himself. Only a sysadmin
can.


> 
> 
> Someone raised shared directories and SGID.  When we get to SGID we've
> stepped slightly outside simple, but I'll allow it.
> 
> Let's say now jkirk wants to share specific files with wriker, and
> specific other files with ksingh.  Let's tackle ksingh first.
> 
> jkirk could put a directory in a shared location, with SGID,
> accessible by jkirk, and have the sysadmin give ksingh the jkirk
> group.  This would, of course, also allow ksingh into anything else
> accessible by jkirk's group--so if his home directory is open, or if
> he has a file shared with wriker by putting wriker in the jkirk group,
> those files are also accessible by ksingh as a matter of course.
> 
> Repeat:  those OTHER files are also accessible by ksingh as a matter of 
> course.
> 
> Instead, ksingh could have jkirk put in the ksingh group; this creates
> the same problem for ksingh.
> 
> Next of course jkirk tries to create a shared directory to share some
> files with wriker, but of course that makes things complex.  Maybe
> wriker does it, but then he shares with ksingh, which means wriker has
> the same problem of jkirk getting files he wants to only share with
> ksingh, or jkirk must accept the problem of sharing files with ksingh
> when he only wants those files to go to wriker (and with wriker when
> he wants those files only to go to ksingh).
> 
> Then, everybody gives up and just uses e-mail to send files back and forth.
> 
> Instead, jkirk creates a directory to share with ksingh.  The
> directory is mode 700, owned by jkirk, and in the group 'users', and
> with the SGID bit set (so not mode 700, more mode 02700?  I forget
> what's SUID, SGID, and sticky, ok?).  He right clicks on it, hits
> Properties, Permissions, adds ksingh with rwx (remember X on
> directories is "access files inside").  When jkirk or ksingh creates
> files inside, they are read/write by group and automatically in the
> group 'users', so jkirk and ksingh can access all files in the
> directory.

This only works if the user default umask is 002, which wouldn't be the
case if you're not using User Private Groups.

Marc.


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Default group

[John Moser]

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, Group, and Other.

 - Integrate into the UI (Konqueror, Gnome)

 - "Apply ACL to Enclosed Files" button to apply the ACL all the way down.

 - Possibly "Apply Permissions to Enclosed Files" button for only UNIX 
permissions


i.e. something more obvious and intuitive.

On 10/17/2012 05:12 PM, Matt Wheeler wrote:


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
mailto:john.r.mo...@gmail.com>> 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 all day about theoretical use cases, but everybody is
going to have differing opinions that lean in odd directions until
certain things are fixed.  Or in short, as long as POSIX ACLs require
a scout badge in command line comfort, discussing how to leverage
POSIX ACLs is pointless because people don't want to think two steps
out.

Let's see if we can get anything agreeable on that.  It'll probably
look strikingly like Windows' Security tab, except without supplying
Allow/Deny, fine grained special permissions (which don't exist), or
having all the Windows main permissions.  So, it'll look like the only
thing that makes sense in general, and specifically for Unix.  That
is, a few rows of controls for Owner, Group, and then a list box of
permissions with one row with three checkboxes per row for each user
(Owner, Group, Everyone, individual users/groups).

Can we get that?

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com

Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss



-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Default group

[John Moser]

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 accessible
to other users.


Yeah I just looked and saw that, my whole $HOME is world-readable.

This displeases me.  I'd prefer default $HOME chmod 700.




A user can't change permissions on his $HOME by himself. Only a sysadmin
can.


$ ls -ld ~
drwxr--r-x 100 bluefox bluefox 4096 Oct 14 11:47 /home/bluefox
$ chmod go-rx ~
$ ls -ld ~
drwx-- 100 bluefox bluefox 4096 Oct 14 11:47 /home/bluefox
$ setfacl -m u:root:r ~
$ getfacl ~
# file: home/bluefox
# owner: bluefox
# group: bluefox
user::rwx
user:root:r--
group::---
mask::r--
other::---

Try again.



This only works if the user default umask is 002, which wouldn't be the
case if you're not using User Private Groups.


Well, it's the case now; and if we leave it the case and make ACL 
handling more intuitive, then it'll all work.  Changing $HOME to 700 
instead of 755 would adequately protect the user's private files in 
$HOME even with a umask of 002, since you simply can't look into $HOME 
to read/modify those files anyway.


The only other thing needed would then be a "Shared Documents" alike 
(borrowing from Windows again--it's a pile of crap but that doesn't mean 
everything associated is terrible by default) supplying a place for 
folks to put shared files or such secured shared folders, made sticky of 
course.





Marc.




--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Default group

[Marc Deslauriers]

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.
>>
>> In a default Ubuntu installation, jkirk's files are already accessible
>> to other users.
> 
> Yeah I just looked and saw that, my whole $HOME is world-readable.
> 
> This displeases me.  I'd prefer default $HOME chmod 700.

As I said, we wanted people to be able to share files by default without
having to understand granting permissions. This has already been
discussed to death, although it's been a while.

> 
>>
>>
>> A user can't change permissions on his $HOME by himself. Only a sysadmin
>> can.
> 
> $ ls -ld ~
> drwxr--r-x 100 bluefox bluefox 4096 Oct 14 11:47 /home/bluefox
> $ chmod go-rx ~
> $ ls -ld ~
> drwx-- 100 bluefox bluefox 4096 Oct 14 11:47 /home/bluefox
> $ setfacl -m u:root:r ~
> $ getfacl ~
> # file: home/bluefox
> # owner: bluefox
> # group: bluefox
> user::rwx
> user:root:r--
> group::---
> mask::r--
> other::---
> 
> Try again.

Of course, you're absolutely right. I'm not sure what I was thinking
there for a sec. :P

> 
>>
>> This only works if the user default umask is 002, which wouldn't be the
>> case if you're not using User Private Groups.
> 
> Well, it's the case now; and if we leave it the case and make ACL
> handling more intuitive, then it'll all work.  Changing $HOME to 700
> instead of 755 would adequately protect the user's private files in
> $HOME even with a umask of 002, since you simply can't look into $HOME
> to read/modify those files anyway.

I'm not sure this proposal would be simple enough to be understood by
most non-technical users. Also, last time we looked at using extended
attributes, there were issues with proper support in common tools,
backup software, certain filesystems, etc. This would need to be looked
at again to see if extended attributes can be used now. It's certainly
worth investigating it again.

> 
> The only other thing needed would then be a "Shared Documents" alike
> (borrowing from Windows again--it's a pile of crap but that doesn't mean
> everything associated is terrible by default) supplying a place for
> folks to put shared files or such secured shared folders, made sticky of
> course.

Well, right now we're defaulting to sharing everything except private
information in private directories. Your proposal is basically to share
nothing, and create exceptions. If this is to be discussed again, we
probably need to figure out if our users are able to understand file
permissions well enough to be able to share documents.

Of course, this is all moot without home directory encryption, and when
you turn that on, there's basically no sharing at all.

Marc.



-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Default group

[John Moser]

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-readable, as must any
files.


In a default Ubuntu installation, jkirk's files are already accessible
to other users.


Yeah I just looked and saw that, my whole $HOME is world-readable.

This displeases me.  I'd prefer default $HOME chmod 700.


As I said, we wanted people to be able to share files by default without
having to understand granting permissions. This has already been
discussed to death, although it's been a while.



It's good to revisit things.  I'm bringing up what's turning into an 
evolving alternate proposal, at this point I've gotten as far out as 
suggesting UI changes and a sticky bit (= /tmp) directory acting as a 
"Shared Documents" between users, which I'm guessing didn't come up last 
round.  Sometimes the rules change.




Of course, you're absolutely right. I'm not sure what I was thinking
there for a sec. :P


Wrong facility probably.  Changing permission != changing group, which 
is what this discussion started on.





I'm not sure this proposal would be simple enough to be understood by
most non-technical users. Also, last time we looked at using extended
attributes, there were issues with proper support in common tools,
backup software, certain filesystems, etc. This would need to be looked
at again to see if extended attributes can be used now. It's certainly
worth investigating it again.


I may as well continue beating the "Look at Windows" horse, it's done 
this right for ages anyway.  You should consider your user base though: 
 they've already installed Ubuntu.  Most of them.  Some probably got a 
tablet or such that came with it, but single-user systems likely do not 
care.  We're talking about shared multi-user systems where everyone 
isn't admin, which is kind of a narrow case.


That's less "most users don't need to know how" and more "most users 
won't be faced by a sudden, surprising, confusing change" (like moving 
from Gnome2 to Ubiquity or Gnome3 by default?).  In other words, I 
suspect most users aren't particularly attached to the "sharing my files 
with everyone else" case.


Finally on that discussion, the current case is--as discussed--a default 
"Share with everyone, and the user has to take an unknown technical step 
to stop that."  That means it's hard (for some value of "hard") for some 
14 year old girl to stop her little brother from reading her diary. 
Fortunately actual e-mails are stored in a directory Thunderbird by 
default forces to 700, although any attachments you save you'll need to 
purposely revoke permission on.  Mostly to the point, documents, saved 
attachments, saved files off Web sites, PDF collections of Victorian era 
pornography downloaded from torrents, all by default available without 
jumping through technical hoops.




Don't know about common tools, backup software.  I'm well aware it's not 
straight out-of-box supported by Thunar, Nautilus, and Konqueror--it 
works, but their file properties dialogs don't let you manage those 
permissions.  Again, Windows does this right.




As for filesystems, POSIX ACLs tend to cause issues with read latency 
for inodes not in disk cache.  XFS with 256 byte inodes takes something 
like 9uS to read a non-ACL inode, 7000uS for an ACL inode; XFS with 512 
byte inodes takes 9us either way; and other file systems tend to behave 
like XFS with 256 byte inodes (9uS-15uS without POSIX ACL, 1000-1500mS 
with it).  This is because another seek-and-read must be done.  Not a 
problem on SSD. not a problem on a warm system, minor performance issue 
at first boot.  This isn't something that's going to slow the system to 
a crawl:  these ACLs are only going to be set on user-owned files, and 
even then the proposed semantics favor setting them on a directory here 
and there and so you lose a millisecond or three once in a great while.


Do note that performance issues are circa 2003: 
http://users.suse.com/~agruen/acl/linux-acls/online/








The only other thing needed would then be a "Shared Documents" alike
(borrowing from Windows again--it's a pile of crap but that doesn't mean
everything associated is terrible by default) supplying a place for
folks to put shared files or such secured shared folders, made sticky of
course.


Well, right now we're defaulting to sharing everything except private
information in private directories. Your proposal is basically to share
nothing, and create exceptions. If this is to be discussed again, we
probably need to figure out if our users are able to understand file
permissions well enough to be able to share documents.


I recall Windows XP notifying users that it was in fact going to 
"privatize" directories after upgrade, or some such.  Such flip-flops 
have been