Permissions advice needed.

Brett Davidson brett at net24.co.nz
Tue Jan 9 20:07:13 UTC 2007


To clarify a point, the following line, 

This works well as this is the only non-root suid file on the system

should be replaced with 

This works well as this is the only "non-root accessable" suid file on
the system.

Cheers,
Brett.


-----Original Message-----
From: owner-freebsd-questions at freebsd.org
[mailto:owner-freebsd-questions at freebsd.org] On Behalf Of Brett Davidson
Sent: Wednesday, 10 January 2007 8:53 a.m.
To: freebsd-questions at freebsd.org
Subject: FW: Permissions advice needed.

-----Original Message-----
From: Malcolm Kay [mailto:malcolm.kay at internode.on.net]
Sent: Tuesday, 9 January 2007 6:03 p.m.
To: freebsd-questions at freebsd.org
Cc: Brett Davidson
Subject: Re: Permissions advice needed.

On Tue, 9 Jan 2007 06:13 am, Brett Davidson wrote:
> I have a curious problem.
>
> I need an executable file to be owned by a user's uid and gid so they 
> can run it.

Malcolm: A user does not need to own a file to be able to run it. All
they need is execute permission. So what is the real problem?

Brett: This file is being run via suexec in Apache, so yes, both uid and
gid need to match in order for the file to be run. 
This particular system is running a shared-hosting webserver and
utilising php-cgi and suexec appears to be the easiest way of providing
inter-site isolation.
The only problem with that is that you need a wrapper in order to
provide customised php.ini settings for each site via the PHPRC
environment variable. That wrapper is the file I am concerned about
here.

> HOWEVER, I don't want them to be able to modify or delete the file 
> and/or it's permissions. Another program will do that.

Malcolm: Deleting or creating a file requires write access in the
directory containg the file reference -- it has nothing to do with the
permissions on the file itself.

Brett:I only want one particular file in the directory to be untouchable
so directory permissions aren't helpful. Directory permissions only go
part of the way as the file has to be read-only as well.

Anyway, for what it's worth, I have found a fix; in FreeBSD 6.2 the
MAC_BSDEXTENDED filesystem firewall has been enhanced.

If I use that, make the file suid (harmless since it's already owned by
the user),  then the ugidfw rule below all works well :

"ugidfw add subject not uid 0 object suid rx"

This works well as this is the only non-root suid file on the system. In
other systems where this may not be the case the rule should still be
harmless as these suid files SHOULD only have rx permissions for
non-root users anyway. :-)

The only gotcha to that would be during program upgrades performed via a
non-root user; the rule will either need to be relaxed or an additional
specific rule could be placed above it to allow suid modifications to
any specific non-root owned programs that may be in place. 

Cheers,
Brett.


>
> This, under standard Unix permissions, is a tad difficult. :-)
>
> ACL's don't help here as the owner of a file has the ability to change

> permissions.
>
> I could set the immutable bit (Linux term for the schg flag) but the 
> modifying program does not recognise this flag and will thus fail to 
> modify the file.
> (I have no control over the modifying program).
>
> Any ideas?
>
> I don't want to go down the line of using BSD MAC but I'm starting to 
> think I may have too just to be able to prevent the user from 
> modifying ONE file! (I'm not even sure I could implement this using 
> MAC anyway).
>
> Cheers,
> Brett.
> _______________________________________________
> freebsd-questions at freebsd.org mailing list 
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to
> "freebsd-questions-unsubscribe at freebsd.org"
_______________________________________________
freebsd-questions at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribe at freebsd.org"


More information about the freebsd-questions mailing list