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 done.

Users will probably not understand anything until it's happened to them 
once or twice.  A Shared Documents folder where such things would go to 
be shared would wind up by default having files in it that everyone can 
read, and folders by default being readable and writable by everyone, 
with files in those folders readable and writable by everyone.  The user 
would still have to take action to tighten it down--not something that 
can be helped, but something that we can facilitate.


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

/home/shared not encrypted.

And we're relying on the graces of nobody jacking the machine with a 
bootable USB drive, yes.  These are, in the end, just soft barriers.

> Marc.
>
>
>