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