Linux Setuid special permission flag with read/write

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite












Does the setuid is only applicable for execute file(only applicable with executable flags) ?



How it will affect other permission(read/write) of same file !



Eg:- If the the actual file permission is 4711, non-owner user can't read it. Why its not elevating the owner permission 4711 and allow others to read the content.







share|improve this question



















  • Because allowing others to read it is 04.
    – Ignacio Vazquez-Abrams
    May 4 at 6:13










  • Yes, but my doubt is since i set, setuid(4000), can't the file make user of owner permission(7 [ rws ~> rwx ]). There by allow the other to read/write/execute it.
    – Vaisakh Rajagopal
    May 4 at 6:16














up vote
0
down vote

favorite












Does the setuid is only applicable for execute file(only applicable with executable flags) ?



How it will affect other permission(read/write) of same file !



Eg:- If the the actual file permission is 4711, non-owner user can't read it. Why its not elevating the owner permission 4711 and allow others to read the content.







share|improve this question



















  • Because allowing others to read it is 04.
    – Ignacio Vazquez-Abrams
    May 4 at 6:13










  • Yes, but my doubt is since i set, setuid(4000), can't the file make user of owner permission(7 [ rws ~> rwx ]). There by allow the other to read/write/execute it.
    – Vaisakh Rajagopal
    May 4 at 6:16












up vote
0
down vote

favorite









up vote
0
down vote

favorite











Does the setuid is only applicable for execute file(only applicable with executable flags) ?



How it will affect other permission(read/write) of same file !



Eg:- If the the actual file permission is 4711, non-owner user can't read it. Why its not elevating the owner permission 4711 and allow others to read the content.







share|improve this question











Does the setuid is only applicable for execute file(only applicable with executable flags) ?



How it will affect other permission(read/write) of same file !



Eg:- If the the actual file permission is 4711, non-owner user can't read it. Why its not elevating the owner permission 4711 and allow others to read the content.









share|improve this question










share|improve this question




share|improve this question









asked May 4 at 6:12









Vaisakh Rajagopal

84




84











  • Because allowing others to read it is 04.
    – Ignacio Vazquez-Abrams
    May 4 at 6:13










  • Yes, but my doubt is since i set, setuid(4000), can't the file make user of owner permission(7 [ rws ~> rwx ]). There by allow the other to read/write/execute it.
    – Vaisakh Rajagopal
    May 4 at 6:16
















  • Because allowing others to read it is 04.
    – Ignacio Vazquez-Abrams
    May 4 at 6:13










  • Yes, but my doubt is since i set, setuid(4000), can't the file make user of owner permission(7 [ rws ~> rwx ]). There by allow the other to read/write/execute it.
    – Vaisakh Rajagopal
    May 4 at 6:16















Because allowing others to read it is 04.
– Ignacio Vazquez-Abrams
May 4 at 6:13




Because allowing others to read it is 04.
– Ignacio Vazquez-Abrams
May 4 at 6:13












Yes, but my doubt is since i set, setuid(4000), can't the file make user of owner permission(7 [ rws ~> rwx ]). There by allow the other to read/write/execute it.
– Vaisakh Rajagopal
May 4 at 6:16




Yes, but my doubt is since i set, setuid(4000), can't the file make user of owner permission(7 [ rws ~> rwx ]). There by allow the other to read/write/execute it.
– Vaisakh Rajagopal
May 4 at 6:16










1 Answer
1






active

oldest

votes

















up vote
0
down vote



accepted










A non-owner can't read the file because setuid and setgid only affect the effective permissions when the file is executed; otherwise, the file permissions are used. Here's an example program to try:



readme.c



#include <stdio.h>

int main(int argc, char **argv)
FILE *f;
int i;
char c;

if(argc>1)
f=fopen(argv[1],"rb");
for(i=1; i++<100;)
c=getc(f);
printf("%x%s", (int)c, i%50?" ":"n");

fclose(f);




Compile it and change its permissions as someone other than who you want to test with (I used root):



# gcc -Wall -o readme readme.c
# chown root:root readme
# chmod ug+s,o-rw readme


Verify the permissions and try reading the file as your test user:



erik ~ $ ls -la readme
-rwsr-s--x 1 root root 8064 May 4 12:05 readme
erik ~ $ cat readme
cat: readme: Permission denied


Now try running the program and have it read itself:



erik ~ $ ./readme readme
7f 45 4c 46 2 1 1 0 0 0 0 0 0 0 0 0 3 0 3e 0 1 0 0 0 fffffff0 5 0 0 0 0 0 0 40 0 0 0 0 0 0 0 40 18 0 0 0 0 0 0 0
0 0 0 40 0 38 0 9 0 40 0 1d 0 1c 0 6 0 0 0 4 0 0 0 40 0 0 0 0 0 0 0 40 0 0 0 0 0 0 0 40 0 0 0 0 0 0 0 fffffff8 1 0


You'll see it had no problems, because the effective permissions changed to a user with read permissions.



Why does this happen? Several reasons come to mind. First, there's no real need for anyone to have read permissions to run an executable because the kernel (which loads the program) has full permissions to do anything already. You only need to have read permissions if you want to view the contents of the executable file, usually so you can copy the file. It's possible, to name some possible examples, that the executable has sensitive data that users shouldn't see (which is strongly discouraged, but has happened!) or the system is using this as a defence in depth to prevent people from finding exploits.






share|improve this answer





















    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    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',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );








     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f441709%2flinux-setuid-special-permission-flag-with-read-write%23new-answer', 'question_page');

    );

    Post as a guest






























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    0
    down vote



    accepted










    A non-owner can't read the file because setuid and setgid only affect the effective permissions when the file is executed; otherwise, the file permissions are used. Here's an example program to try:



    readme.c



    #include <stdio.h>

    int main(int argc, char **argv)
    FILE *f;
    int i;
    char c;

    if(argc>1)
    f=fopen(argv[1],"rb");
    for(i=1; i++<100;)
    c=getc(f);
    printf("%x%s", (int)c, i%50?" ":"n");

    fclose(f);




    Compile it and change its permissions as someone other than who you want to test with (I used root):



    # gcc -Wall -o readme readme.c
    # chown root:root readme
    # chmod ug+s,o-rw readme


    Verify the permissions and try reading the file as your test user:



    erik ~ $ ls -la readme
    -rwsr-s--x 1 root root 8064 May 4 12:05 readme
    erik ~ $ cat readme
    cat: readme: Permission denied


    Now try running the program and have it read itself:



    erik ~ $ ./readme readme
    7f 45 4c 46 2 1 1 0 0 0 0 0 0 0 0 0 3 0 3e 0 1 0 0 0 fffffff0 5 0 0 0 0 0 0 40 0 0 0 0 0 0 0 40 18 0 0 0 0 0 0 0
    0 0 0 40 0 38 0 9 0 40 0 1d 0 1c 0 6 0 0 0 4 0 0 0 40 0 0 0 0 0 0 0 40 0 0 0 0 0 0 0 40 0 0 0 0 0 0 0 fffffff8 1 0


    You'll see it had no problems, because the effective permissions changed to a user with read permissions.



    Why does this happen? Several reasons come to mind. First, there's no real need for anyone to have read permissions to run an executable because the kernel (which loads the program) has full permissions to do anything already. You only need to have read permissions if you want to view the contents of the executable file, usually so you can copy the file. It's possible, to name some possible examples, that the executable has sensitive data that users shouldn't see (which is strongly discouraged, but has happened!) or the system is using this as a defence in depth to prevent people from finding exploits.






    share|improve this answer

























      up vote
      0
      down vote



      accepted










      A non-owner can't read the file because setuid and setgid only affect the effective permissions when the file is executed; otherwise, the file permissions are used. Here's an example program to try:



      readme.c



      #include <stdio.h>

      int main(int argc, char **argv)
      FILE *f;
      int i;
      char c;

      if(argc>1)
      f=fopen(argv[1],"rb");
      for(i=1; i++<100;)
      c=getc(f);
      printf("%x%s", (int)c, i%50?" ":"n");

      fclose(f);




      Compile it and change its permissions as someone other than who you want to test with (I used root):



      # gcc -Wall -o readme readme.c
      # chown root:root readme
      # chmod ug+s,o-rw readme


      Verify the permissions and try reading the file as your test user:



      erik ~ $ ls -la readme
      -rwsr-s--x 1 root root 8064 May 4 12:05 readme
      erik ~ $ cat readme
      cat: readme: Permission denied


      Now try running the program and have it read itself:



      erik ~ $ ./readme readme
      7f 45 4c 46 2 1 1 0 0 0 0 0 0 0 0 0 3 0 3e 0 1 0 0 0 fffffff0 5 0 0 0 0 0 0 40 0 0 0 0 0 0 0 40 18 0 0 0 0 0 0 0
      0 0 0 40 0 38 0 9 0 40 0 1d 0 1c 0 6 0 0 0 4 0 0 0 40 0 0 0 0 0 0 0 40 0 0 0 0 0 0 0 40 0 0 0 0 0 0 0 fffffff8 1 0


      You'll see it had no problems, because the effective permissions changed to a user with read permissions.



      Why does this happen? Several reasons come to mind. First, there's no real need for anyone to have read permissions to run an executable because the kernel (which loads the program) has full permissions to do anything already. You only need to have read permissions if you want to view the contents of the executable file, usually so you can copy the file. It's possible, to name some possible examples, that the executable has sensitive data that users shouldn't see (which is strongly discouraged, but has happened!) or the system is using this as a defence in depth to prevent people from finding exploits.






      share|improve this answer























        up vote
        0
        down vote



        accepted







        up vote
        0
        down vote



        accepted






        A non-owner can't read the file because setuid and setgid only affect the effective permissions when the file is executed; otherwise, the file permissions are used. Here's an example program to try:



        readme.c



        #include <stdio.h>

        int main(int argc, char **argv)
        FILE *f;
        int i;
        char c;

        if(argc>1)
        f=fopen(argv[1],"rb");
        for(i=1; i++<100;)
        c=getc(f);
        printf("%x%s", (int)c, i%50?" ":"n");

        fclose(f);




        Compile it and change its permissions as someone other than who you want to test with (I used root):



        # gcc -Wall -o readme readme.c
        # chown root:root readme
        # chmod ug+s,o-rw readme


        Verify the permissions and try reading the file as your test user:



        erik ~ $ ls -la readme
        -rwsr-s--x 1 root root 8064 May 4 12:05 readme
        erik ~ $ cat readme
        cat: readme: Permission denied


        Now try running the program and have it read itself:



        erik ~ $ ./readme readme
        7f 45 4c 46 2 1 1 0 0 0 0 0 0 0 0 0 3 0 3e 0 1 0 0 0 fffffff0 5 0 0 0 0 0 0 40 0 0 0 0 0 0 0 40 18 0 0 0 0 0 0 0
        0 0 0 40 0 38 0 9 0 40 0 1d 0 1c 0 6 0 0 0 4 0 0 0 40 0 0 0 0 0 0 0 40 0 0 0 0 0 0 0 40 0 0 0 0 0 0 0 fffffff8 1 0


        You'll see it had no problems, because the effective permissions changed to a user with read permissions.



        Why does this happen? Several reasons come to mind. First, there's no real need for anyone to have read permissions to run an executable because the kernel (which loads the program) has full permissions to do anything already. You only need to have read permissions if you want to view the contents of the executable file, usually so you can copy the file. It's possible, to name some possible examples, that the executable has sensitive data that users shouldn't see (which is strongly discouraged, but has happened!) or the system is using this as a defence in depth to prevent people from finding exploits.






        share|improve this answer













        A non-owner can't read the file because setuid and setgid only affect the effective permissions when the file is executed; otherwise, the file permissions are used. Here's an example program to try:



        readme.c



        #include <stdio.h>

        int main(int argc, char **argv)
        FILE *f;
        int i;
        char c;

        if(argc>1)
        f=fopen(argv[1],"rb");
        for(i=1; i++<100;)
        c=getc(f);
        printf("%x%s", (int)c, i%50?" ":"n");

        fclose(f);




        Compile it and change its permissions as someone other than who you want to test with (I used root):



        # gcc -Wall -o readme readme.c
        # chown root:root readme
        # chmod ug+s,o-rw readme


        Verify the permissions and try reading the file as your test user:



        erik ~ $ ls -la readme
        -rwsr-s--x 1 root root 8064 May 4 12:05 readme
        erik ~ $ cat readme
        cat: readme: Permission denied


        Now try running the program and have it read itself:



        erik ~ $ ./readme readme
        7f 45 4c 46 2 1 1 0 0 0 0 0 0 0 0 0 3 0 3e 0 1 0 0 0 fffffff0 5 0 0 0 0 0 0 40 0 0 0 0 0 0 0 40 18 0 0 0 0 0 0 0
        0 0 0 40 0 38 0 9 0 40 0 1d 0 1c 0 6 0 0 0 4 0 0 0 40 0 0 0 0 0 0 0 40 0 0 0 0 0 0 0 40 0 0 0 0 0 0 0 fffffff8 1 0


        You'll see it had no problems, because the effective permissions changed to a user with read permissions.



        Why does this happen? Several reasons come to mind. First, there's no real need for anyone to have read permissions to run an executable because the kernel (which loads the program) has full permissions to do anything already. You only need to have read permissions if you want to view the contents of the executable file, usually so you can copy the file. It's possible, to name some possible examples, that the executable has sensitive data that users shouldn't see (which is strongly discouraged, but has happened!) or the system is using this as a defence in depth to prevent people from finding exploits.







        share|improve this answer













        share|improve this answer



        share|improve this answer











        answered May 4 at 18:19









        ErikF

        2,6711413




        2,6711413






















             

            draft saved


            draft discarded


























             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f441709%2flinux-setuid-special-permission-flag-with-read-write%23new-answer', 'question_page');

            );

            Post as a guest













































































            Popular posts from this blog

            Peggy Mitchell

            Palaiologos

            The Forum (Inglewood, California)