All your permissions are belong to us

39 thoughts on “All your permissions are belong to us”

1. The whole of the dialogue is showing the current state of the permissions for that file…

   Except the “chmod” part, which launches a command for which you wouldn’t see the output, or whether it’s worked at all.

   Also, when would it be applied? There’s no button to apply it, and changing it when unfocusing the text widget looks a recipe for disaster.

   Being able to run arbitrary commands on the file itself, and the subdirectories would be a better idea, IMO.

2. Just a thought, but I suspect the word “recursive” may have most non-CS people shaking their heads. Maybe “Apply changes to everything in this folder?”, while somewhat less clear to you and me, would be infinitely more clear to someone who didn’t understand recursion

3. The recursive application lacks “discoverability”. I certainly don’t want to poke around with something that dangerous (I can lock myself out of my files) which has “instant apply”, just to find out how to do it recursively.

   And what about the “ooops” button on you “prompt for recursivitiy” dialog? You acknowledge that the user cannot reverse easily, but you don’t offer a easy way out.

   I suggest highlighting the original values with some special color/outline, so users can feel safer in changing the permissions.

4. Bastien:

   > The whole of the dialogue is showing the current state of the permissions for that file…
   > Except the “chmod” part, which launches a command for which you wouldn’t see the output, or whether it’s worked at all.

   The “chmod” part doesn’t launch a command. We parse the string using code from the GNU coreutils, convert it into a GnomeVFSFilePermissions mask and apply it ourselves. How else could I have stated that this also works for remote shares? You will at least be notified that it is applying your changes with a watch cursor, and you will be notified by an error dialog about failed changes.

   > Also, when would it be applied? There’s no button to apply it, and changing it when unfocusing the text widget looks a recipe for disaster.

   You have to press enter when the entry is focused. That’s IMHO how people who use shells denote “I’m fine with my command, now run it!”.

   Paul:

   > Just a thought, but I suspect the word “recursive” may have most non-CS people shaking their heads.

   Did you note that I’m presenting two different dialogs, depending on whether the entry resembling chmod was used or not?

5. Florin:

   > The recursive application lacks “discoverability”.

   Maybe you could explain why?

   > I certainly don’t want to poke around with something that
   > dangerous (I can lock myself out of my files) which has
   > “instant apply”, just to find out how to do it recursively.

   Well, you can’t lock yourself out of your files, at least not using the drop down entries. The “None” entry is not available in user’s “Access” dropdown.

   > And what about the “ooops” button on you “prompt for
   > recursivitiy” dialog? You acknowledge that the user cannot
   > reverse easily, but you don’t offer a easy way out.

   I assume that the user wants to change permissions of the folder, so I can assume that he wants Nautilus to modify at least the permissions of the folder itself.

   > I suggest highlighting the original values with some
   > special color/outline, so users can feel safer in changing
   > the permissions.

   What original values? The original values are preselected in the drop-downs.

6. i think you’ve pretty much nailed it. very good!

   just two comments:
   1. i would change the label “chmod” to “chmod (enter to apply)”
   2. i woulnd’t have two different dialogs to ask if the user wants recursive or not recursive action. i would only keep the “simple” version.
   3. i’m not certain separating “execute” rights for owner/group/other is needed, but why not. some might object because of clutter but ok it gives power without forcing going to the command-line. and avoids a regression from gnome 2.12.

   this version is unbelievably better than you version #2. i didn’t think it’s possible to make a so good one.

7. btw by the “simple” version i meant the version for non-UNIX experts. the one that doesn’t mention “recursive”. experts will understand both versions. so there’s no need for an expert version IMHO.

8. Some distributions use seperate groups for each user. How would the group drop-down work in a system with 100 or 1000 groups? Is there a threshold where the drop-down becomes a text-field?
   I also agree that looking at the dialog doesn’t clue you in on how to change permissions recursively, I recon a user looking to do this can do a fair amount of looking around before realising it’s worked into the close button (I don’t believe users read manuals or help files generally). At the same time, if you’re not looking to recursively change permissions, you would still get that question each time you want to change permission for a file.
   These changes are looking nice otherways.

9. >At the same time, if you’re not looking to recursively change >permissions, you would still get that question each time you >want to change permission for a file.

   no, everytime you change permission for a directory, or a selection containing a directory: so it’s quite OK, it makes sense in the end.

10. Hi,

    while the recursive-thingie does lack discoverability in the advanced mode, I think it’s fine in the dropdown-mode of the dialog.

    Why?

    Because non-professional users don’t open that dialog with the idea to recusively change permissions – mostly because it does not occur to them that there are two possible outcomes of their changing permission.

    They just visit the dialog, make the changes and then, when that question pops up, learn that there are two possiblities and THEN decide.

    Questions:

    1) What happens if I close the recursive-question-dialog with the X? Yeah. nothing in the file system is changed, but what happens? Is the dialog closed? Does the dialog stay open but nothing changes? How to close then?

    2) IMHO, that permissions thing is more of a nuiscance than anything else for the casual user. I friend of mine is using Mac OS X and the only time he comes across the permission stuff is when he’s using that “fix permissions”-feature of the disk utility. Maybe this functionality can even removed?

    Other than that, I really, really like the dialog design here.

    Philip

11. emmanuel:

    > i would change the label “chmod” to “chmod (enter to apply)”

    Thanks for that suggestion, adding a small italicized “press enter to apply” right below the entry will probably do the trick.

    > btw by the “simple” version i meant the version for non-UNIX experts. the one that doesn’t mention “recursive”. experts
    > will understand both versions. so there’s no need for an expert version IMHO.

    Using chmod and afterwards being told that recursive permission changes may pose a risk is simply stupid. I just want to make sure to not add noise to the workflow of people who know exactly what they want and describe it in their language, and as terse as possible.

    Martin:

    > Some distributions use seperate groups for each user. How would the group drop-down work in a system with 100 or 1000 groups? Is there a threshold where the drop-down becomes a text-field?

    Thank you for bringing this up. Most of the time, the user names seem to be very short, so maybe we can lay them out in a table grid, using gtk_combo_box_set_wrap_width to display five groups in a row or so. Of course this method doesn’t scale arbitrarily well, but how common is it to be a member of more than a few dozen of groups?

    Philip:

    > What happens if I close the recursive-question-dialog with the X?

    It will be closed, the properties dialog itself will be kept open, and the permission button that triggered the modification request will be set back to the state before the change was requested.

    > IMHO, that permissions thing is more of a nuiscance than anything else for the casual user.

    I agree, but there are situations where you have to make scripts executable (cf. use case 1) or make a directory copied from a read-only location r/w.

12. I:

    > Martin:

    > > Some distributions use seperate groups for each user. How would the group drop-down work in a system with 100 or
    > > 1000 groups? Is there a threshold where the drop-down becomes a text-field?

    > Thank you for bringing this up. Most of the time, the user names seem to be very short, so maybe we can lay them out in
    > a table grid, using gtk_combo_box_set_wrap_width to display five groups in a row or so. Of course this method
    > doesn’t scale arbitrarily well, but how common is it to be a member of more than a few dozen of groups?

    Let me add that only the groups are listed where you are a member.

13. >It will be closed, the properties dialog itself will be kept open, and the permission button that triggered the modification request will be set back to the state before the change was requested.

    is it clear for the user that the changes have been undone? Maybe add a third button anyways stating something like “Quit and don’t do anything”, closing both the question and the permissions dialog

    >I agree, but there are situations where you have to make scripts executable (cf. use case 1) or make a directory copied from a read-only location r/w.

    Are there? The r/w-ing could be done for the user. And marking files read-only is something that mostly just confuses users when it happens by accident and which never happens on purpose (*sigh* – just thinking of my parents here).

    I agree though that making executable is a corner-case, but why not threat scrips as normal files and always run them via the interpreter. No need to make them executable then.

    An advanced user capable of writing a script and running it from the command line (where your existing methods of opening a file with an application don’t work) is aware of the implications and thus able to do the CHMODing.

    I’d say: Make this dialog as inaccessible as possible and maybe really just provide the chmod-argument-part and try to work for/with the user for the other cases.

    – Scripts? Manually run them via the interpreter
    – Making ro-stuff copied from CDs rw? Just do it. (only for the owner of course).

    I feel quite confident that the whole permissions-thing can be abstracted away, so not even that “fix permissions” option as known in OS X is needed any more.

    As this will require some major work, I’m not saying it must be done now. I’m just suggesting to make some research in that direction (above things are not completely thought-out. Just ideas). For now, your dialog is perfect IMHO, though I’m still looking forward to the time when it will be possible to remove it from Nautilus 😉

    Philip

14. Holy cow.. How about “No” and “Yes” on that last dialog? Do you really need to be that verbose to answer a simple yes or no question, “Apply Changes Recursively?”?

    Damn.

15. What if you want to change the owner, group, and other permissions for a directory with 100’000 files or more?

    This could take a long time, and the user has to wait after each change (eg. for the owner), before he can choose the next (eg. for the group). So instead of waiting once (at the end of his changes), he has to wait three times (after each change)…

16. Does an Advanced mode really add anything? If I wanted to use chmod, I would open a terminal and use chmod. When I open the file properties dialogue, I want a simple click interface.

    The advanced mode is only necessary if you are offering enriched functionality that doesn’t exist in the basic mode. In this case, there are only a few marginal corner cases (i.e. u-r) that are exposed.

    As mentioned previously (and already acknowledged) the message needs help. It is ridiculously verbose, certainly enough to scare off most users (myself included!). I also object to the scary tone in the message. It’s not THAT dangerous and it can be undone with relative ease, especially since you can’t revoke your own read access.

    And finally a question: If you modify the User access and Group access rights on a directory, would you be queried twice about wanting to propagate the changes recursively?

17. Oh! And why not simply allowing -R in the chmod window?

18. You should ask the user if they want the changes to be applied to subfolders too. The average Joe has no clue what recursion is.

19. good work. looking forward to seeing this once the few little problems have been worked out.

    “apply to contents” might be a better wording.

20. Hey, look, I can actually be useful for once! Here’s a proofread on the dialog:

    s/You can apply these changes to the folder itself only/You can apply these changes only to the folder itself/

    s/to its whole contents/to everything it contains/

    Marginals: “cannot” is more commonly used than “can not”, though both are correct. That would be a style guide issue for most publications, but I suspect GNOME is not yet sufficently old and gnarly to have a style guide 🙂

21. I like what I see, but am struck with this idea. In posix, the executable bit means something different on directories than it does on files.

    If I am editing directory permissions, perhaps the basic mode should not even show permissions, the executable bit would follow the readable bit?

22. A thought about the “Apply changes recursively” dialog:
    I’m don’t know the HIG, but I think the buttons should either be yes/no (short quick to understand) or they should be something like Apply recursively/directory only

    “Apply recursively” and “Don’t Apply recursively” are IMHO hard to tell apart with a quick glance because they are long and differ only in the first word.

23. Of course, “Details” does not actually offer any “details”, but rather “the same information in old-school-UNIXspeak”. It’s not clear why this section exists. If you want the Terminal, you know where to find it; would it help us to add a terminal-like interface to the bottom of every window?

    Also, it doesn’t fix the biggest problem I have with the existing dialog box: there’s no way to change the owner of a file, and for no apparent reason.

    “May run file as application” is just weird (even though I know what it does), as is underlining a different letter (y, r, then n) in each instance of it. (This hints to me that tab-focus is as broken here as it is in the save-file-dialog-box.)

    But most damning: When I see that somebody has designed a dialog box with 59(!) words, and then describes a use case where “Jimmy reads the text carefully”, I’m inclined to think that this person has never done any user testing. I’ve done quite a bit, and I can’t imagine any user, of any level of expertise, who would meet this monstrosity with anything other than profanity. (As a bonus, it has no “Cancel” option. Yay, no way out!)

    I applaud wanting to design an improved interface for permissions, but I think you need to go back to the drawing board.

24. I really feel like the chmod:_______ is really not very Gnome HIG compliant at all.

    There was a discussion at some point of replacing Ctrl+L in the GtkFileDialog with manual type being triggered upon typing / or ~ — the only uses of which could be for manually typing in a path.

    Perhaps the same logic could be applied here? Perhaps if + or – are typed in, a small dialog appears for chmod syntax? That would achieve the HIG’s end of not including something as cryptic as chmod on the interface while allowing power users to chmod as effortlessly as possible. Hitting + or – are not common mistake keys, so it’s unlikely somebody would hit them by mistake.

    -jag

25. “Jimmy reads the text carefully.”

    Thanks for making me laugh, this is the funniest thing I’ve seen all day.

26. You could have more descriptive text for the directory modes; new users are often confused by the way permissions apply to directories. I’d suggest something like: “List contents”, “Change into directory” and “Create files”.

    And what about the 4th set of bits? While it’s arguable that most bits are useful to new users, the set-GID is and is often underutilized. Perhaps a checkbox like ‘New files inherit this group’ ?

27. My glade skills are not worth much, but what about an obvious apply button and recursive checkbox for the detailed mode?

    http://img475.imageshack.us/img475/934/skrmdumpwindow17qq.png

28. Okay, but what if the filesytem isn’t using UNIX permissions?

    Making Nautilus always check for permissions is a design fault, and is only usefull in situations where the system uses UNIX permissions. Unfortunately there is no way to turn this off, which makes nautilus totally unusefull on other ACL-like systems.

    Take for example AFS (Andrew Filesystem), which is a distributed FS, with finegrained access control lists. A big with nautilus is that AFS UID != UNIX UID, which gives problems because, fx. it’s “create new folder” function, checks for correct unix permissions on the dir before giving the user the option to create new folders. This means that i have 200 users, that cannot create folders with nautilus, but if they drop to terminal, and type `mkdir test`, the system call is sent to the kernel, and then the kernel will tell if the user can or cannot create the folder…

    Why isn’t it possible to turn nautilus permissions extension totally off?

29. Just a thought, but why can’t there be two permissions dialogs for folders. One for the directory and one for the directories contents. The differnce in the two being that the directory’s permissions dialog could read “Can View Contents” instead of read, “Can Add and Delete files” intead of write and “Can Browse” instead of execute. The ideas of read and write as applied to a directory arn’t usually that apparent. If they could be renamed in the case of a directory it would probably help. If recursive permission setting is needed coudldn’t it be with a spererate dialog, or is that too cluttered?

30. Thanks for all your productive input! The variety of comments shows that this is an extremely difficult topic, because permissions are perceived and used completely different by you.

    To everybody pointing out that the wording of the advanced recursive question dialog is overengineered and confusing: You are right, the final implementation will probably contain Yes/No or at least better distinguishable labels.

    The basic confirmation dialog will also be made less scary. As I said, the wording is not perfect, I just put together random aspects of permission modification.

    I’m still not sure whether offering a cancel button buys us much for the dialog, I think you almost never want to cancel this operation.

    Janne:

    > What if you want to change the owner, group, and other permissions for a directory with 100’000 files or more?

    > This could take a long time, and the user has to wait after each change (eg. for the owner), before he can choose
    > the next (eg. for the group).

    Is this really a common use-case? If so, can you please point out how to achieve this more quickly with the shell, where you also have to wait for chmod until you can apply chrgrp.

    Mike:

    > If I wanted to use chmod, I would open a terminal and use chmod. When I open the file properties dialogue, I want a
    > simple click interface.

    Our goal is that you should not have to use the terminal at all, as explained under [1]. If we don’t have a way to modify the permissions in an arbitrary manner, we won’t be taken seriously by advanced users.

    > If you modify the User access and Group access rights on a directory, would you be queried twice about wanting to
    > propagate the changes recursively?

    Yes.

    Pete:

    > If I am editing directory permissions, perhaps the basic mode should not even show permissions, the executable bit would follow the readable bit?

    Yes.

    > It’s not clear why (the details) section exists. If you want the Terminal, you know where to find it; would it help
    > us to add

    Because we don’t expose all aspects of *NIX permissions in the basic mode, but users may be willing to toggle each of the bits. Also, one label doesn’t cost much wrt space and it allows us to put the textual/octal representation of the file somewhere, just in case the user is interested.

    > a terminal-like interface to the bottom of every window?

    No, but where it makes sense. I’m convinced it does make sense here, and only here. Where else would you like to see them?

    Also, it doesn’t fix the biggest problem I have with the existing dialog box: there’s no way to change the owner of a file, and for no apparent reason.

    > “May run file as application” is just weird (even though I know what it does), as is underlining a different letter (y,
    > r, then n) in each instance of it. (This hints to me that tab-focus is as broken here as it is in the
    > save-file-dialog-box.)

    I just wanted to make sure that there are no mnemonic clashes, so that every function can be reached with two keypresses. I’m not sure whether this is more important than being able to keynav through all the executability widgets.

    jag:

    I must say that your proposal also is a viable and at least equally good solution, though Alex pointed out in an email [2] that he doesn’t like this kind of subwindow.

    Wil:

    > You could have more descriptive text for the directory modes; new users are often confused by the way permissions
    > apply to directories. I’d suggest something like: “List contents”, “Change into directory” and “Create files”.

    Users could also select files and diretories at once, so we should IMHO keep the terminology consistent. “Read” in this context means rx, i.e. “List contents” and “CHange into directory”, “Read and Write” means rwx, i.e. “List contents”, “Change into directory” and “Create files”. I think this is obvious enough.

    > And what about the 4th set of bits? While it’s arguable that most bits are useful to new users, the set-GID is and
    > is often underutilized. Perhaps a checkbox like ‘New files inherit this group’ ?

    That’s why we have the chmod entry. Almost nobody is aware of these features, so they just confuse, and you can still set[ug]id.

    ulrik:

    In what way is an apply button better than an entry and a tiny text describing that you have press enter to apply, as proposed by emmanuel? Adding a recursion button would be confusing because it clashes with the semantics of the basic dialogs, i.e. the dialog. I just don’t see its advantage, except when used in additional dialog as proposed by jag.

    Johan:

    > Making Nautilus always check for permissions is a design fault (…) .

    You are describing an extreme edge case. Why don’t you hack something like this into Nautilus? I doubt many others need this, and if they need it, it could be a configure-time flag we would like to have upstream. Go for it! 🙂

    Arthur: The advanced mode of my second proposal looked like that and it horribly failed. Please come up with a mockup or some illustration how you keep the widget count low, and still offer this feature.

    [1] http://live.gnome.org/UnixPowerForDesktop
    [2] http://mail.gnome.org/archives/nautilus-list/2006-January/msg00064.html

31. for enterprise needs (and even power users) we need _official_ file acl in nautilus.

    it’s pretty important for sharing works.

32. > > [100’000 files…]
    > > This could take a long time, and the user has to wait after each change (eg. for the owner), before he can choose
    > > the next (eg. for the group).
    > Is this really a common use-case? If so, can you please point out how to achieve this more quickly with the shell,
    > where you also have to wait for chmod until you can apply chrgrp.

    Hmm, I don’t know if it is a common-use case 🙂 I haven’t used Linux very much yet. On the command line you can at least change all the access rights at once with chmod, which you can’t in your new Nautilus basic access rights dialog.

    But OK, if it is a rare case, then you can of course input the chmod line directly in the advanced mode in those cases.

    Otherwise than this detail and some other ones mentioned in the comments (discoverability of recursive action in the advanced mode) I think that your new dialog is already much better than the current one.

33. Yeah, pretty cool! nice job 😀
    i love this feature , but it could be a little better with possibilty to change the owner (chown) , with a gksudo interaction obviously!

34. michel:

    > for enterprise needs (and even power users) we need _official_ file acl in nautilus

    You are absolutely right, also applies to my company. Found this on planet.gnome.org (Alvaro is working on ACL support for nautilus):
    http://blogs.sun.com/roller/page/alvaro?entry=nautilus_acl_support

35. michel:

    There is also Eiciel for editing ACL’s:
    http://rofi.pinchito.com/eiciel/

36. Being able to change permissions recursively in the graphical enivironment is a very welcome feature.

    I hope I didn’t miss anyone suggesting it already, but what about just putting the following buttons to the main window:

    Cancel
    Apply to folder
    Apply to folder and contents

    I think it would be nice not to have the extra window for this.

37. This project hits the nail right on the head, since the Nautilus’ way of handling permissions is rather poorly engineered. After more than three years of being KDE user exclusively I switched to Gnome/Ubuntu cause I finally found things to be easier and more logical in Gnome than in KDE. Still, if vanity is put aside 😉 Gnome devs could learn something from their KDE colleagues, esp. when this issue comes up. So, please take a look at Konqueror’s way of dealing with this, I find it a bit more user-friendly (yeah, I know…)

    http://flickr.com/photos/pivarac/109397591/

38. Really, it’s better without additional dialogs. Simple “Apply to Folder contents” button will be far more usable and far less annoying.

39. I think is just great.

Comments are closed.