Re: Giving a webuser rights to files created by apache under his homedir.

On Monday 04 July 2005 10:01, Marius Karthaus wrote:
> Hi Andreas,
>
> The way the directories, ownership and permissions are set up is not the
> problem, on my system people are not able to get to files that are not
> within their own webtree, not even with cgi scripting they write
> themselves. People may use php and perl or any other CGI that they like.
> Even binary programs are no problem This is truely solved by the way
> i've set up unix perms on my system.
>
> PHP has built in safety measures (openbasedir/safemode etc) and CGI is
> executed using SuExec under the users own UID/GID. There is no way that
> user EARL can read or modify BOB's files.
> Even if user BOB makes a subdir in his webroot for his own squirelmail
> install and he makes this dir mod 777 like the manual tells him to do,
> user EARL will not have any possible way to get to those files, not with
> CGI, nor with PHP. Trust me this is a setup that has worked for me for
> years.
>
> The only problem that my users have is that with their FTP (user)
> account they are unable to alter files that are created by apache .
> Ofcourse they can unlink and re-create. But not overwrite or modify...
> try explaining this to a regular user!
> This i was hoping to solve this with ACL.
>
> The problem (bug?) i'm having with acl is in short this:
> (i've made a totaly different setup here to show you that the problem
> occurs in other situation too, so this is not the same as the last
> example and does not represent my real problem it just an example)
>
> ### i have 3 users in the group 'people':
> web1:/tmp# groups bob
> bob : people
> web1:/tmp# groups john
> john : people
> web1:/tmp# groups earl
> earl : people
>
> ### lets give bob a homedir that only he can have xs to:
> web1:/tmp# mkdir bobs_dir
> web1:/tmp# chown bob:people bobs_dir/
> web1:/tmp# chmod 700 bobs_dir/
> web1:/tmp# ls -la
> drwx------   2 bob  people 4096 Jul  4 09:39 bobs_dir
>
> ### now let user john in this dir and set the default rights for all
> files and dirs that are going to be created inside bobs_dir:
> ### notice that i am explicitly denying any "group" and "other" rights
> here: web1:/tmp# setfacl -m u:john:rwx -m g::- -m o::- bobs_dir/
> web1:/tmp# setfacl -d -m u:john:rwx -m g::- -m o::- bobs_dir/
>
> ### so lets look at the result:
> web1:/tmp# getfacl bobs_dir/
> # file: bobs_dir
> # owner: bob
> # group: people
> user::rwx
> user:john:rwx
> group::---
> mask::rwx
> other::---
> default:user::rwx
> default:user:john:rwx
> default:group::---
> default:mask::rwx
> default:other::---

You want to add user bob to the default acl as well.

> ### as you can see ACL says that both "group" and "others" have no
> rights to bobs dir and that only "user" and "user:john" can rwx this
> dir. Seems OK doesn't it? Just what i want to happen
>
> web1:/tmp# ls -al
> drwxrwx---+  2 bob  people 4096 Jul  4 09:39 bobs_dir
>
> Why do normal unix permissions think that group has rights here?

The group class permission bits (the three middle ones) correspond to the mask 
entry is a mask entry exists. This does not imply that group people has any 
rights.

> This is 
> very bad! I explicitly told my system to deny group rights on all
> occasions.  Lets say that somehow this file system gets mounted without
> ACL options!.

That would obviously be a security hole. Don't do this.

> In this case what *should* happen is that John no longer 
> has 'extra' rights because of ACL has disappeard...But instead ALL users
> in group people now have full rights to BOBs dir. Seems like a mayor
> security flaw to me.

Setting ACLs and then disabling them by mounting without ACL support is not a 
safe thing to do, and it was never intended to be. Making it fail "closed" 
would imply a significant performance penalty.

> This also confuses things like SuExec. This module chowns to a UID/GID
> only if it knows for sure that the dir that the CGI script lives in
> cannot be altered by any other users. It fails because it now thinks
> that all "people" can do this here.

I think you really mean SuExec does seteuid. The test that SuExec uses is 
incorrect in the presence of ACLs: It only checks the file mode permission 
bits, but that's not enough. If should also check the acl entries.

The more relevant point here is that you give users bob as well as john write 
access to the directory. This is exactly the case that SuExec tries to catch, 
because it's generally unsafe.

In case you want to discuss this any further, please come up with a complete 
example. It's really a waste of time otherwise.

-- Andreas.
_______________________________________________
acl-devel mailing list
[email protected]
http://acl.bestbits.at/mailman/listinfo/acl-devel