Default group

Thu Oct 18 07:05:24 UTC 2012

I agree that there should be something done on the UI to support ACL on
Ubuntu (not like eiciel). But I really don't agree when you say that
Windows is already doing it well!
Honnestly, nobody never understood these pretty technical concepts of
permissions (I mean usual end-users, not us that are talking on a dev linux
distrib mailing-list). I still organize some gaming LAN with friends (on
Windows of course ...) and most of the time, when someone want to share
something, they prefer :
- copy their things to an external DD
- give the external DD to their friend
- the friend then copy the content on his local disk
Although they're all connected to a gigabit switch, using the external disk
is not the fastest but it's the simpler. I already explained how to make a
network share but it involved too much computer skills : IP, filesystem,
permissions, network share... So they continue to use their external disk.
I don't even try to explain it anymore ;)

Conclusion: instead of creating an UI that just reflects the low level
understanding of ACL which won't help the majority of peoples we need
something better. In a UI, things needs to be astracted. So we should think
about "sharing" as a Service like in SAAS: you really don't know which
technical configuration is involved but it works. So I think that a
"sharing" options should launch a wizard wich ask simple questions that do
not involve any technical skills (but with some hints for technical guys)
like :
1) to who do you want to share the directory:
a: another user on this computer
b: another computer on my local network (LAN) (#maybe that using something
like webdav would be simpler than Samba or NFS?)
c: someone which is connected to internet like me (# and then using
something in the cloud like Ubuntu One?)
2) Is the other user can delete and modify the content or only see it?

The wizard do whatever needed for it to work : modify filesystem
permissions, configure a Samba Share, or a Webdav service ... At the end of
the wizard, it tells the instructions to give to the other guy how to
access the share (give an url and saying to type it in their internet
browser, a path and saying how to use it...).

To go further, I think "sharing" should even not be implemented into
nautilus or other file browser! It should be something standalone with a
shortcut in the dash, which opens a windows like the system configuration
one with some icons like :
- see my current shares
- create a new share
- connect to a share that someone gave me

What do you think?

Nicolas

2012/10/18 John Moser <john.r.moser at gmail.com>

>
>
> 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/<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 at lists.**ubuntu.com<Ubuntu-devel-discuss at lists.ubuntu.com>
> Modify settings or unsubscribe at: https://lists.ubuntu.com/**
> mailman/listinfo/ubuntu-devel-**discuss<https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss>
>

-- 
Nicolas MICHEL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20121018/516ee1cb/attachment.html>