[ale] Unexpected behavior

[Denny Chambers]

Hi all,

    I was playing around with a program today, and ran in to what I 
thought was an unexpected behavior. I am not an expert at linux/unix 
programming, so maybe I have done something wrong, or I have the wrong 
expectations. I have a program that runs as root (yea I know, you don't 
have to say it), and may access files on the behalf of other users. To 
do this I set the euid and egid of the user in question. Then I attempt 
a fopen operation on the file. This seems to work pretty well except for 
one case I found where the rules seem to get violated, and a security 
hole opens up.

So let me set up the scenario:

First here is a simple test program I use:

--start copy
#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>

main(int argc, char *argv) {
    FILE *fd = NULL;

    setegid(100);
    seteuid(501);
    if((fd = fopen("./foo", "r")) != NULL){
        printf("User (%d/%d) has rights to file\n", geteuid(), getegid());
    }
    else{
        printf("User (%d/%d) does not have rights file\n", geteuid(), 
getegid());
    }
}
--stop copy

I have two users:

guser (good user) with uid 500 and gid 100
buser (bad user) with uid 501 and gid 100

I have created a group in which buser is not a member  of. We will call 
this group test1

I have a file or directory, will call it foo:

getfacl foo shows:

# file: foo
# owner: guser
# group: test1
user::rwx
group::rwx
other::---

I run the code above as root, it sets the effective uid and gid and 
attempts to open the file. It fails and the user does not get access to 
the file.

now I do a chgrp root foo.

getfacl foo shows:

# file: foo
# owner: guser
# group: root
user::rwx
group::rwx
other::---

I run the code above as root, it sets the effective uid and gid and 
attempts to open the file. This time it succeeds and the user does get 
access to the file.

I have tested this on ext3, xfs with extended attribute, and xfs with 
out extended attribute, and this problem occurs. On XFS with extended 
attribute, it doesn't matter if the owning group is root or if the root 
group is assign through setfacl, it gives up access.

I also try adding the root at as the file owner or adding right s 
through ACLs, having the user root on the file does not seem to be a 
problem, only the group.

Anyone have any thoughts on this?

Denny



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3435 bytes
Desc: S/MIME Cryptographic Signature