How do I list the effective file permission in Linux?Do I correctly understand permission to directories in...

It grows, but water kills it

Taxes on Dividends in a Roth IRA

Why does Carol not get rid of the Kree symbol on her suit when she changes its colours?

How to get directions in deep space?

Multiplicative persistence

Why is so much work done on numerical verification of the Riemann Hypothesis?

Are Captain Marvel's powers affected by Thanos breaking the Tesseract and claiming the stone?

What are some good ways to treat frozen vegetables such that they behave like fresh vegetables when stir frying them?

Can you use Vicious Mockery to win an argument or gain favours?

Shouldn’t conservatives embrace universal basic income?

Why should universal income be universal?

Mimic lecturing on blackboard, facing audience

Is this part of the description of the Archfey warlock's Misty Escape feature redundant?

How to preserve electronics (computers, iPads and phones) for hundreds of years

Which Article Helped Get Rid of Technobabble in RPGs?

A Trivial Diagnosis

What (the heck) is a Super Worm Equinox Moon?

Is there a way to have vectors outlined in a Vector Plot?

The Digit Triangles

Stack Interview Code methods made from class Node and Smart Pointers

What is the difference between lands and mana?

Does "he squandered his car on drink" sound natural?

Does the Linux kernel need a file system to run?

What kind of floor tile is this?



How do I list the effective file permission in Linux?


Do I correctly understand permission to directories in Linux/Unix?How to make new file permission inherit from the parent directory?Unix set file permission as another fileCommand to list permission of file and all folders from root to the file's pathWhy do you need execute permission on the parent directory to rename a fileWhat is the difference between the special permission and execution permissionList file permissions for a directory and its parentsChange group or permissions when a file is moved to a shared directory on LinuxLinux folder and file permissionsLinux permission of parent directory more restrictive than child is normal?













6















i.e:



Suppose the directory permission is 700, and the file under the directory is 570



Then the effective permission of the file is 500



Is there such a command that lists the effective permission by recursively checking parent permissions?










share|improve this question















migrated from stackoverflow.com Dec 13 '12 at 18:08


This question came from our site for professional and enthusiast programmers.























    6















    i.e:



    Suppose the directory permission is 700, and the file under the directory is 570



    Then the effective permission of the file is 500



    Is there such a command that lists the effective permission by recursively checking parent permissions?










    share|improve this question















    migrated from stackoverflow.com Dec 13 '12 at 18:08


    This question came from our site for professional and enthusiast programmers.





















      6












      6








      6


      1






      i.e:



      Suppose the directory permission is 700, and the file under the directory is 570



      Then the effective permission of the file is 500



      Is there such a command that lists the effective permission by recursively checking parent permissions?










      share|improve this question
















      i.e:



      Suppose the directory permission is 700, and the file under the directory is 570



      Then the effective permission of the file is 500



      Is there such a command that lists the effective permission by recursively checking parent permissions?







      linux unix file-permissions






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Dec 14 '12 at 0:38









      Scott

      16k113990




      16k113990










      asked Dec 13 '12 at 11:40







      user1608776











      migrated from stackoverflow.com Dec 13 '12 at 18:08


      This question came from our site for professional and enthusiast programmers.









      migrated from stackoverflow.com Dec 13 '12 at 18:08


      This question came from our site for professional and enthusiast programmers.
























          4 Answers
          4






          active

          oldest

          votes


















          4














          There is no such command and no simple way to do it, especially as both the file and the directories might have ACLs set in addition to the traditional permissions making the effective file permissions more complex to compute and display.
          Moreover, your question assumes there is a single path to the file but symbolic links potentially presents in the path should be first resolved as their permissions do not matter, the file might also have multiple hard-links so might be reachable from another directory. The user might also be able to access it through a different path if either loopback/bind mounts are in place or the user is running in a chrooted environment.



          In any case, what you can do is to impersonate a user and check if the file while accessed through a given path is readable, writable and/or executable by him/her.



          Something like:



          #!/bin/ksh
          [[ $# != 2 ]] && { echo Usage $0 user file; exit ; }
          dir=$(cd $(dirname "$2");/bin/pwd)
          file=$(basename "$2")
          su $1 ksh -c '
          cd $2 2>/dev/null || { echo "---" ; exit ; }
          [[ -r "$3" ]] && p=r || p=-
          [[ -w "$3" ]] && p=${p}w || p=${p}-
          [[ -x "$3" ]] && p=${p}x || p=${p}-
          printf "%s %s/%sn" $p "$2" "$3"
          ' "$1" "$dir" "$file"


          This will show the effective rights for the user on that particular file using the traditional rwx syntax. Note that this script might give false negative results if the user launching has not root privileges (or equivalent) and has no read access on the target directory.






          share|improve this answer





















          • 1





            You make several excellent points: Different hard links to the same inode can have different “effective permissions” if they are in different directories. Users can access directories through chroot or mount points that they wouldn’t be able to access directly. (Of course this applies to remote network mounts as well as loopback mounts.) One caveat: the user should use your script with an absolute path. If I cd deep into my directory structure and then run your script on a relative filename, that will defeat the point.

            – Scott
            Dec 14 '12 at 20:52











          • @Scott, thanks for the comment, script updated to fix that issue.

            – jlliagre
            Dec 15 '12 at 7:21











          • I’m not sure that works. Consider (1) I type cd ~/private/dir1, where private is 700 and dir1 is 755, and type foo fred myfile, where foo is your script and myfile is 644. Your script will su to fred, (successfully) cd to ., and report r–– — even though fred has no access to ~/scott/private. (2) I cd ~/dir2/dir3, where dir2 and dir3 are 755, and type foo fred ../myfile2, where myfile2 is a file in dir2. Your script will cd to .. (dir2) and then try to access ../myfile2 — which doesn’t exist, relative to dir2.

            – Scott
            Dec 17 '12 at 22:48











          • @Scott, you are right again. Fixed.

            – jlliagre
            Dec 17 '12 at 23:10



















          2














          This is not so very easy to solve. Especially, the "effective" file permissions (a concept which is in this context unknown to me) is not so easy to determine.



          You can access a file if all the directories leading to it are "executable". If you know the file's names, you do not need read access.



          (E. g., sometimes, I make home directories 710 in order to give x access to other members of the same group. So no one else sees what I have in my ~, but they can use it if I tell them what is there.)



          If the question is about accessing an existing file, the answer is different from creating or removing a file. In the latter case, the parent directory of the file(-to-be) bust be writable.



          OTOH, if I do not have the x of a directory in the file's path, I cannot even determine if the file exists, and thus also not which permissions the file has. You can argue that then the effective permission would be 0, but I don't find it sensible to tell something about file permissions when I don't even know if the file exists.



          But if you want so, you take the mask of each directory, do & 0111, & the masks together, and if there is a 0 where a 1 should be, you put a 0 into the file's "effective permission".



          For creating and removing, you determine the parent directory's effective permission and look if it is writable and executable.



          So in a 700 directory, a 570 becomes 500.






          share|improve this answer


























          • What’s your point? To quote you, “This scenario says that I – as owner – … cannot modify the file.” In other words, the owner has read+execute permission. Everybody else has no access — hence, the effective permission is 500. The fact that a different set of parameters (directory = 500, file = 600) has a different result doesn’t invalidate the example that the OP gave.

            – Scott
            Dec 14 '12 at 0:51













          • @Scott My point is that this is a bad example, because it might suggest that you just have to AND together the mask and get the result. This is not the case. But maybe I just got this wrong from my understanding...

            – glglgl
            Dec 14 '12 at 7:11











          • @Scott I made more thoughts about it and rephrased the complete answer.

            – glglgl
            Dec 14 '12 at 7:21











          • Well, systems that have ACLs (including *nix and Windows) have a concept of “effective permission(s)”, but they generally deal only with the interaction of ACEs within one ACL, and not with the directories leading up (down?) to the target.

            – Scott
            Dec 14 '12 at 20:51



















          1














          The other answers are correct. However you can use a bash one-liner to list the permissions of the directory hierarchy. First change to the directory in question, and then run:



          pushd .; while [ `pwd` != / ]; do ls -ld `pwd`; cd ..; done; popd





          share|improve this answer
























          • Thank you for posting this. Very useful for a quick overview.

            – semtex41
            Feb 24 '17 at 16:25



















          0














          You can use namei with option -m or -l, and then do the calculation yourself.



          $ namei -l /home/theuser/.ssh/authorized_keys
          f: /home/theuser/.ssh/authorized_keys
          dr-xr-xr-x root root /
          drwxr-xr-x root root home
          drwx------ theuser users theuser
          drwxr-xr-x theuser users .ssh
          -rw------- theuser users authorized_keys





          share|improve this answer























            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "3"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f518964%2fhow-do-i-list-the-effective-file-permission-in-linux%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown
























            4 Answers
            4






            active

            oldest

            votes








            4 Answers
            4






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            4














            There is no such command and no simple way to do it, especially as both the file and the directories might have ACLs set in addition to the traditional permissions making the effective file permissions more complex to compute and display.
            Moreover, your question assumes there is a single path to the file but symbolic links potentially presents in the path should be first resolved as their permissions do not matter, the file might also have multiple hard-links so might be reachable from another directory. The user might also be able to access it through a different path if either loopback/bind mounts are in place or the user is running in a chrooted environment.



            In any case, what you can do is to impersonate a user and check if the file while accessed through a given path is readable, writable and/or executable by him/her.



            Something like:



            #!/bin/ksh
            [[ $# != 2 ]] && { echo Usage $0 user file; exit ; }
            dir=$(cd $(dirname "$2");/bin/pwd)
            file=$(basename "$2")
            su $1 ksh -c '
            cd $2 2>/dev/null || { echo "---" ; exit ; }
            [[ -r "$3" ]] && p=r || p=-
            [[ -w "$3" ]] && p=${p}w || p=${p}-
            [[ -x "$3" ]] && p=${p}x || p=${p}-
            printf "%s %s/%sn" $p "$2" "$3"
            ' "$1" "$dir" "$file"


            This will show the effective rights for the user on that particular file using the traditional rwx syntax. Note that this script might give false negative results if the user launching has not root privileges (or equivalent) and has no read access on the target directory.






            share|improve this answer





















            • 1





              You make several excellent points: Different hard links to the same inode can have different “effective permissions” if they are in different directories. Users can access directories through chroot or mount points that they wouldn’t be able to access directly. (Of course this applies to remote network mounts as well as loopback mounts.) One caveat: the user should use your script with an absolute path. If I cd deep into my directory structure and then run your script on a relative filename, that will defeat the point.

              – Scott
              Dec 14 '12 at 20:52











            • @Scott, thanks for the comment, script updated to fix that issue.

              – jlliagre
              Dec 15 '12 at 7:21











            • I’m not sure that works. Consider (1) I type cd ~/private/dir1, where private is 700 and dir1 is 755, and type foo fred myfile, where foo is your script and myfile is 644. Your script will su to fred, (successfully) cd to ., and report r–– — even though fred has no access to ~/scott/private. (2) I cd ~/dir2/dir3, where dir2 and dir3 are 755, and type foo fred ../myfile2, where myfile2 is a file in dir2. Your script will cd to .. (dir2) and then try to access ../myfile2 — which doesn’t exist, relative to dir2.

              – Scott
              Dec 17 '12 at 22:48











            • @Scott, you are right again. Fixed.

              – jlliagre
              Dec 17 '12 at 23:10
















            4














            There is no such command and no simple way to do it, especially as both the file and the directories might have ACLs set in addition to the traditional permissions making the effective file permissions more complex to compute and display.
            Moreover, your question assumes there is a single path to the file but symbolic links potentially presents in the path should be first resolved as their permissions do not matter, the file might also have multiple hard-links so might be reachable from another directory. The user might also be able to access it through a different path if either loopback/bind mounts are in place or the user is running in a chrooted environment.



            In any case, what you can do is to impersonate a user and check if the file while accessed through a given path is readable, writable and/or executable by him/her.



            Something like:



            #!/bin/ksh
            [[ $# != 2 ]] && { echo Usage $0 user file; exit ; }
            dir=$(cd $(dirname "$2");/bin/pwd)
            file=$(basename "$2")
            su $1 ksh -c '
            cd $2 2>/dev/null || { echo "---" ; exit ; }
            [[ -r "$3" ]] && p=r || p=-
            [[ -w "$3" ]] && p=${p}w || p=${p}-
            [[ -x "$3" ]] && p=${p}x || p=${p}-
            printf "%s %s/%sn" $p "$2" "$3"
            ' "$1" "$dir" "$file"


            This will show the effective rights for the user on that particular file using the traditional rwx syntax. Note that this script might give false negative results if the user launching has not root privileges (or equivalent) and has no read access on the target directory.






            share|improve this answer





















            • 1





              You make several excellent points: Different hard links to the same inode can have different “effective permissions” if they are in different directories. Users can access directories through chroot or mount points that they wouldn’t be able to access directly. (Of course this applies to remote network mounts as well as loopback mounts.) One caveat: the user should use your script with an absolute path. If I cd deep into my directory structure and then run your script on a relative filename, that will defeat the point.

              – Scott
              Dec 14 '12 at 20:52











            • @Scott, thanks for the comment, script updated to fix that issue.

              – jlliagre
              Dec 15 '12 at 7:21











            • I’m not sure that works. Consider (1) I type cd ~/private/dir1, where private is 700 and dir1 is 755, and type foo fred myfile, where foo is your script and myfile is 644. Your script will su to fred, (successfully) cd to ., and report r–– — even though fred has no access to ~/scott/private. (2) I cd ~/dir2/dir3, where dir2 and dir3 are 755, and type foo fred ../myfile2, where myfile2 is a file in dir2. Your script will cd to .. (dir2) and then try to access ../myfile2 — which doesn’t exist, relative to dir2.

              – Scott
              Dec 17 '12 at 22:48











            • @Scott, you are right again. Fixed.

              – jlliagre
              Dec 17 '12 at 23:10














            4












            4








            4







            There is no such command and no simple way to do it, especially as both the file and the directories might have ACLs set in addition to the traditional permissions making the effective file permissions more complex to compute and display.
            Moreover, your question assumes there is a single path to the file but symbolic links potentially presents in the path should be first resolved as their permissions do not matter, the file might also have multiple hard-links so might be reachable from another directory. The user might also be able to access it through a different path if either loopback/bind mounts are in place or the user is running in a chrooted environment.



            In any case, what you can do is to impersonate a user and check if the file while accessed through a given path is readable, writable and/or executable by him/her.



            Something like:



            #!/bin/ksh
            [[ $# != 2 ]] && { echo Usage $0 user file; exit ; }
            dir=$(cd $(dirname "$2");/bin/pwd)
            file=$(basename "$2")
            su $1 ksh -c '
            cd $2 2>/dev/null || { echo "---" ; exit ; }
            [[ -r "$3" ]] && p=r || p=-
            [[ -w "$3" ]] && p=${p}w || p=${p}-
            [[ -x "$3" ]] && p=${p}x || p=${p}-
            printf "%s %s/%sn" $p "$2" "$3"
            ' "$1" "$dir" "$file"


            This will show the effective rights for the user on that particular file using the traditional rwx syntax. Note that this script might give false negative results if the user launching has not root privileges (or equivalent) and has no read access on the target directory.






            share|improve this answer















            There is no such command and no simple way to do it, especially as both the file and the directories might have ACLs set in addition to the traditional permissions making the effective file permissions more complex to compute and display.
            Moreover, your question assumes there is a single path to the file but symbolic links potentially presents in the path should be first resolved as their permissions do not matter, the file might also have multiple hard-links so might be reachable from another directory. The user might also be able to access it through a different path if either loopback/bind mounts are in place or the user is running in a chrooted environment.



            In any case, what you can do is to impersonate a user and check if the file while accessed through a given path is readable, writable and/or executable by him/her.



            Something like:



            #!/bin/ksh
            [[ $# != 2 ]] && { echo Usage $0 user file; exit ; }
            dir=$(cd $(dirname "$2");/bin/pwd)
            file=$(basename "$2")
            su $1 ksh -c '
            cd $2 2>/dev/null || { echo "---" ; exit ; }
            [[ -r "$3" ]] && p=r || p=-
            [[ -w "$3" ]] && p=${p}w || p=${p}-
            [[ -x "$3" ]] && p=${p}x || p=${p}-
            printf "%s %s/%sn" $p "$2" "$3"
            ' "$1" "$dir" "$file"


            This will show the effective rights for the user on that particular file using the traditional rwx syntax. Note that this script might give false negative results if the user launching has not root privileges (or equivalent) and has no read access on the target directory.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Dec 17 '12 at 23:29

























            answered Dec 14 '12 at 6:52









            jlliagrejlliagre

            12k32540




            12k32540








            • 1





              You make several excellent points: Different hard links to the same inode can have different “effective permissions” if they are in different directories. Users can access directories through chroot or mount points that they wouldn’t be able to access directly. (Of course this applies to remote network mounts as well as loopback mounts.) One caveat: the user should use your script with an absolute path. If I cd deep into my directory structure and then run your script on a relative filename, that will defeat the point.

              – Scott
              Dec 14 '12 at 20:52











            • @Scott, thanks for the comment, script updated to fix that issue.

              – jlliagre
              Dec 15 '12 at 7:21











            • I’m not sure that works. Consider (1) I type cd ~/private/dir1, where private is 700 and dir1 is 755, and type foo fred myfile, where foo is your script and myfile is 644. Your script will su to fred, (successfully) cd to ., and report r–– — even though fred has no access to ~/scott/private. (2) I cd ~/dir2/dir3, where dir2 and dir3 are 755, and type foo fred ../myfile2, where myfile2 is a file in dir2. Your script will cd to .. (dir2) and then try to access ../myfile2 — which doesn’t exist, relative to dir2.

              – Scott
              Dec 17 '12 at 22:48











            • @Scott, you are right again. Fixed.

              – jlliagre
              Dec 17 '12 at 23:10














            • 1





              You make several excellent points: Different hard links to the same inode can have different “effective permissions” if they are in different directories. Users can access directories through chroot or mount points that they wouldn’t be able to access directly. (Of course this applies to remote network mounts as well as loopback mounts.) One caveat: the user should use your script with an absolute path. If I cd deep into my directory structure and then run your script on a relative filename, that will defeat the point.

              – Scott
              Dec 14 '12 at 20:52











            • @Scott, thanks for the comment, script updated to fix that issue.

              – jlliagre
              Dec 15 '12 at 7:21











            • I’m not sure that works. Consider (1) I type cd ~/private/dir1, where private is 700 and dir1 is 755, and type foo fred myfile, where foo is your script and myfile is 644. Your script will su to fred, (successfully) cd to ., and report r–– — even though fred has no access to ~/scott/private. (2) I cd ~/dir2/dir3, where dir2 and dir3 are 755, and type foo fred ../myfile2, where myfile2 is a file in dir2. Your script will cd to .. (dir2) and then try to access ../myfile2 — which doesn’t exist, relative to dir2.

              – Scott
              Dec 17 '12 at 22:48











            • @Scott, you are right again. Fixed.

              – jlliagre
              Dec 17 '12 at 23:10








            1




            1





            You make several excellent points: Different hard links to the same inode can have different “effective permissions” if they are in different directories. Users can access directories through chroot or mount points that they wouldn’t be able to access directly. (Of course this applies to remote network mounts as well as loopback mounts.) One caveat: the user should use your script with an absolute path. If I cd deep into my directory structure and then run your script on a relative filename, that will defeat the point.

            – Scott
            Dec 14 '12 at 20:52





            You make several excellent points: Different hard links to the same inode can have different “effective permissions” if they are in different directories. Users can access directories through chroot or mount points that they wouldn’t be able to access directly. (Of course this applies to remote network mounts as well as loopback mounts.) One caveat: the user should use your script with an absolute path. If I cd deep into my directory structure and then run your script on a relative filename, that will defeat the point.

            – Scott
            Dec 14 '12 at 20:52













            @Scott, thanks for the comment, script updated to fix that issue.

            – jlliagre
            Dec 15 '12 at 7:21





            @Scott, thanks for the comment, script updated to fix that issue.

            – jlliagre
            Dec 15 '12 at 7:21













            I’m not sure that works. Consider (1) I type cd ~/private/dir1, where private is 700 and dir1 is 755, and type foo fred myfile, where foo is your script and myfile is 644. Your script will su to fred, (successfully) cd to ., and report r–– — even though fred has no access to ~/scott/private. (2) I cd ~/dir2/dir3, where dir2 and dir3 are 755, and type foo fred ../myfile2, where myfile2 is a file in dir2. Your script will cd to .. (dir2) and then try to access ../myfile2 — which doesn’t exist, relative to dir2.

            – Scott
            Dec 17 '12 at 22:48





            I’m not sure that works. Consider (1) I type cd ~/private/dir1, where private is 700 and dir1 is 755, and type foo fred myfile, where foo is your script and myfile is 644. Your script will su to fred, (successfully) cd to ., and report r–– — even though fred has no access to ~/scott/private. (2) I cd ~/dir2/dir3, where dir2 and dir3 are 755, and type foo fred ../myfile2, where myfile2 is a file in dir2. Your script will cd to .. (dir2) and then try to access ../myfile2 — which doesn’t exist, relative to dir2.

            – Scott
            Dec 17 '12 at 22:48













            @Scott, you are right again. Fixed.

            – jlliagre
            Dec 17 '12 at 23:10





            @Scott, you are right again. Fixed.

            – jlliagre
            Dec 17 '12 at 23:10













            2














            This is not so very easy to solve. Especially, the "effective" file permissions (a concept which is in this context unknown to me) is not so easy to determine.



            You can access a file if all the directories leading to it are "executable". If you know the file's names, you do not need read access.



            (E. g., sometimes, I make home directories 710 in order to give x access to other members of the same group. So no one else sees what I have in my ~, but they can use it if I tell them what is there.)



            If the question is about accessing an existing file, the answer is different from creating or removing a file. In the latter case, the parent directory of the file(-to-be) bust be writable.



            OTOH, if I do not have the x of a directory in the file's path, I cannot even determine if the file exists, and thus also not which permissions the file has. You can argue that then the effective permission would be 0, but I don't find it sensible to tell something about file permissions when I don't even know if the file exists.



            But if you want so, you take the mask of each directory, do & 0111, & the masks together, and if there is a 0 where a 1 should be, you put a 0 into the file's "effective permission".



            For creating and removing, you determine the parent directory's effective permission and look if it is writable and executable.



            So in a 700 directory, a 570 becomes 500.






            share|improve this answer


























            • What’s your point? To quote you, “This scenario says that I – as owner – … cannot modify the file.” In other words, the owner has read+execute permission. Everybody else has no access — hence, the effective permission is 500. The fact that a different set of parameters (directory = 500, file = 600) has a different result doesn’t invalidate the example that the OP gave.

              – Scott
              Dec 14 '12 at 0:51













            • @Scott My point is that this is a bad example, because it might suggest that you just have to AND together the mask and get the result. This is not the case. But maybe I just got this wrong from my understanding...

              – glglgl
              Dec 14 '12 at 7:11











            • @Scott I made more thoughts about it and rephrased the complete answer.

              – glglgl
              Dec 14 '12 at 7:21











            • Well, systems that have ACLs (including *nix and Windows) have a concept of “effective permission(s)”, but they generally deal only with the interaction of ACEs within one ACL, and not with the directories leading up (down?) to the target.

              – Scott
              Dec 14 '12 at 20:51
















            2














            This is not so very easy to solve. Especially, the "effective" file permissions (a concept which is in this context unknown to me) is not so easy to determine.



            You can access a file if all the directories leading to it are "executable". If you know the file's names, you do not need read access.



            (E. g., sometimes, I make home directories 710 in order to give x access to other members of the same group. So no one else sees what I have in my ~, but they can use it if I tell them what is there.)



            If the question is about accessing an existing file, the answer is different from creating or removing a file. In the latter case, the parent directory of the file(-to-be) bust be writable.



            OTOH, if I do not have the x of a directory in the file's path, I cannot even determine if the file exists, and thus also not which permissions the file has. You can argue that then the effective permission would be 0, but I don't find it sensible to tell something about file permissions when I don't even know if the file exists.



            But if you want so, you take the mask of each directory, do & 0111, & the masks together, and if there is a 0 where a 1 should be, you put a 0 into the file's "effective permission".



            For creating and removing, you determine the parent directory's effective permission and look if it is writable and executable.



            So in a 700 directory, a 570 becomes 500.






            share|improve this answer


























            • What’s your point? To quote you, “This scenario says that I – as owner – … cannot modify the file.” In other words, the owner has read+execute permission. Everybody else has no access — hence, the effective permission is 500. The fact that a different set of parameters (directory = 500, file = 600) has a different result doesn’t invalidate the example that the OP gave.

              – Scott
              Dec 14 '12 at 0:51













            • @Scott My point is that this is a bad example, because it might suggest that you just have to AND together the mask and get the result. This is not the case. But maybe I just got this wrong from my understanding...

              – glglgl
              Dec 14 '12 at 7:11











            • @Scott I made more thoughts about it and rephrased the complete answer.

              – glglgl
              Dec 14 '12 at 7:21











            • Well, systems that have ACLs (including *nix and Windows) have a concept of “effective permission(s)”, but they generally deal only with the interaction of ACEs within one ACL, and not with the directories leading up (down?) to the target.

              – Scott
              Dec 14 '12 at 20:51














            2












            2








            2







            This is not so very easy to solve. Especially, the "effective" file permissions (a concept which is in this context unknown to me) is not so easy to determine.



            You can access a file if all the directories leading to it are "executable". If you know the file's names, you do not need read access.



            (E. g., sometimes, I make home directories 710 in order to give x access to other members of the same group. So no one else sees what I have in my ~, but they can use it if I tell them what is there.)



            If the question is about accessing an existing file, the answer is different from creating or removing a file. In the latter case, the parent directory of the file(-to-be) bust be writable.



            OTOH, if I do not have the x of a directory in the file's path, I cannot even determine if the file exists, and thus also not which permissions the file has. You can argue that then the effective permission would be 0, but I don't find it sensible to tell something about file permissions when I don't even know if the file exists.



            But if you want so, you take the mask of each directory, do & 0111, & the masks together, and if there is a 0 where a 1 should be, you put a 0 into the file's "effective permission".



            For creating and removing, you determine the parent directory's effective permission and look if it is writable and executable.



            So in a 700 directory, a 570 becomes 500.






            share|improve this answer















            This is not so very easy to solve. Especially, the "effective" file permissions (a concept which is in this context unknown to me) is not so easy to determine.



            You can access a file if all the directories leading to it are "executable". If you know the file's names, you do not need read access.



            (E. g., sometimes, I make home directories 710 in order to give x access to other members of the same group. So no one else sees what I have in my ~, but they can use it if I tell them what is there.)



            If the question is about accessing an existing file, the answer is different from creating or removing a file. In the latter case, the parent directory of the file(-to-be) bust be writable.



            OTOH, if I do not have the x of a directory in the file's path, I cannot even determine if the file exists, and thus also not which permissions the file has. You can argue that then the effective permission would be 0, but I don't find it sensible to tell something about file permissions when I don't even know if the file exists.



            But if you want so, you take the mask of each directory, do & 0111, & the masks together, and if there is a 0 where a 1 should be, you put a 0 into the file's "effective permission".



            For creating and removing, you determine the parent directory's effective permission and look if it is writable and executable.



            So in a 700 directory, a 570 becomes 500.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Dec 14 '12 at 7:21

























            answered Dec 13 '12 at 15:56









            glglglglglgl

            1,305922




            1,305922













            • What’s your point? To quote you, “This scenario says that I – as owner – … cannot modify the file.” In other words, the owner has read+execute permission. Everybody else has no access — hence, the effective permission is 500. The fact that a different set of parameters (directory = 500, file = 600) has a different result doesn’t invalidate the example that the OP gave.

              – Scott
              Dec 14 '12 at 0:51













            • @Scott My point is that this is a bad example, because it might suggest that you just have to AND together the mask and get the result. This is not the case. But maybe I just got this wrong from my understanding...

              – glglgl
              Dec 14 '12 at 7:11











            • @Scott I made more thoughts about it and rephrased the complete answer.

              – glglgl
              Dec 14 '12 at 7:21











            • Well, systems that have ACLs (including *nix and Windows) have a concept of “effective permission(s)”, but they generally deal only with the interaction of ACEs within one ACL, and not with the directories leading up (down?) to the target.

              – Scott
              Dec 14 '12 at 20:51



















            • What’s your point? To quote you, “This scenario says that I – as owner – … cannot modify the file.” In other words, the owner has read+execute permission. Everybody else has no access — hence, the effective permission is 500. The fact that a different set of parameters (directory = 500, file = 600) has a different result doesn’t invalidate the example that the OP gave.

              – Scott
              Dec 14 '12 at 0:51













            • @Scott My point is that this is a bad example, because it might suggest that you just have to AND together the mask and get the result. This is not the case. But maybe I just got this wrong from my understanding...

              – glglgl
              Dec 14 '12 at 7:11











            • @Scott I made more thoughts about it and rephrased the complete answer.

              – glglgl
              Dec 14 '12 at 7:21











            • Well, systems that have ACLs (including *nix and Windows) have a concept of “effective permission(s)”, but they generally deal only with the interaction of ACEs within one ACL, and not with the directories leading up (down?) to the target.

              – Scott
              Dec 14 '12 at 20:51

















            What’s your point? To quote you, “This scenario says that I – as owner – … cannot modify the file.” In other words, the owner has read+execute permission. Everybody else has no access — hence, the effective permission is 500. The fact that a different set of parameters (directory = 500, file = 600) has a different result doesn’t invalidate the example that the OP gave.

            – Scott
            Dec 14 '12 at 0:51







            What’s your point? To quote you, “This scenario says that I – as owner – … cannot modify the file.” In other words, the owner has read+execute permission. Everybody else has no access — hence, the effective permission is 500. The fact that a different set of parameters (directory = 500, file = 600) has a different result doesn’t invalidate the example that the OP gave.

            – Scott
            Dec 14 '12 at 0:51















            @Scott My point is that this is a bad example, because it might suggest that you just have to AND together the mask and get the result. This is not the case. But maybe I just got this wrong from my understanding...

            – glglgl
            Dec 14 '12 at 7:11





            @Scott My point is that this is a bad example, because it might suggest that you just have to AND together the mask and get the result. This is not the case. But maybe I just got this wrong from my understanding...

            – glglgl
            Dec 14 '12 at 7:11













            @Scott I made more thoughts about it and rephrased the complete answer.

            – glglgl
            Dec 14 '12 at 7:21





            @Scott I made more thoughts about it and rephrased the complete answer.

            – glglgl
            Dec 14 '12 at 7:21













            Well, systems that have ACLs (including *nix and Windows) have a concept of “effective permission(s)”, but they generally deal only with the interaction of ACEs within one ACL, and not with the directories leading up (down?) to the target.

            – Scott
            Dec 14 '12 at 20:51





            Well, systems that have ACLs (including *nix and Windows) have a concept of “effective permission(s)”, but they generally deal only with the interaction of ACEs within one ACL, and not with the directories leading up (down?) to the target.

            – Scott
            Dec 14 '12 at 20:51











            1














            The other answers are correct. However you can use a bash one-liner to list the permissions of the directory hierarchy. First change to the directory in question, and then run:



            pushd .; while [ `pwd` != / ]; do ls -ld `pwd`; cd ..; done; popd





            share|improve this answer
























            • Thank you for posting this. Very useful for a quick overview.

              – semtex41
              Feb 24 '17 at 16:25
















            1














            The other answers are correct. However you can use a bash one-liner to list the permissions of the directory hierarchy. First change to the directory in question, and then run:



            pushd .; while [ `pwd` != / ]; do ls -ld `pwd`; cd ..; done; popd





            share|improve this answer
























            • Thank you for posting this. Very useful for a quick overview.

              – semtex41
              Feb 24 '17 at 16:25














            1












            1








            1







            The other answers are correct. However you can use a bash one-liner to list the permissions of the directory hierarchy. First change to the directory in question, and then run:



            pushd .; while [ `pwd` != / ]; do ls -ld `pwd`; cd ..; done; popd





            share|improve this answer













            The other answers are correct. However you can use a bash one-liner to list the permissions of the directory hierarchy. First change to the directory in question, and then run:



            pushd .; while [ `pwd` != / ]; do ls -ld `pwd`; cd ..; done; popd






            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Jan 30 '13 at 19:22









            Edward AndersonEdward Anderson

            510413




            510413













            • Thank you for posting this. Very useful for a quick overview.

              – semtex41
              Feb 24 '17 at 16:25



















            • Thank you for posting this. Very useful for a quick overview.

              – semtex41
              Feb 24 '17 at 16:25

















            Thank you for posting this. Very useful for a quick overview.

            – semtex41
            Feb 24 '17 at 16:25





            Thank you for posting this. Very useful for a quick overview.

            – semtex41
            Feb 24 '17 at 16:25











            0














            You can use namei with option -m or -l, and then do the calculation yourself.



            $ namei -l /home/theuser/.ssh/authorized_keys
            f: /home/theuser/.ssh/authorized_keys
            dr-xr-xr-x root root /
            drwxr-xr-x root root home
            drwx------ theuser users theuser
            drwxr-xr-x theuser users .ssh
            -rw------- theuser users authorized_keys





            share|improve this answer




























              0














              You can use namei with option -m or -l, and then do the calculation yourself.



              $ namei -l /home/theuser/.ssh/authorized_keys
              f: /home/theuser/.ssh/authorized_keys
              dr-xr-xr-x root root /
              drwxr-xr-x root root home
              drwx------ theuser users theuser
              drwxr-xr-x theuser users .ssh
              -rw------- theuser users authorized_keys





              share|improve this answer


























                0












                0








                0







                You can use namei with option -m or -l, and then do the calculation yourself.



                $ namei -l /home/theuser/.ssh/authorized_keys
                f: /home/theuser/.ssh/authorized_keys
                dr-xr-xr-x root root /
                drwxr-xr-x root root home
                drwx------ theuser users theuser
                drwxr-xr-x theuser users .ssh
                -rw------- theuser users authorized_keys





                share|improve this answer













                You can use namei with option -m or -l, and then do the calculation yourself.



                $ namei -l /home/theuser/.ssh/authorized_keys
                f: /home/theuser/.ssh/authorized_keys
                dr-xr-xr-x root root /
                drwxr-xr-x root root home
                drwx------ theuser users theuser
                drwxr-xr-x theuser users .ssh
                -rw------- theuser users authorized_keys






                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered 10 mins ago









                Andrey RegentovAndrey Regentov

                82611015




                82611015






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Super User!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f518964%2fhow-do-i-list-the-effective-file-permission-in-linux%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    VNC viewer RFB protocol error: bad desktop size 0x0I Cannot Type the Key 'd' (lowercase) in VNC Viewer...

                    Tribunal Administrativo e Fiscal de Mirandela Referências Menu de...

                    looking for continuous Screen Capture for retroactivly reproducing errors, timeback machineRolling desktop...