-----Original Message----- From: Malcolm Kay [mailto:[EMAIL PROTECTED] Sent: Tuesday, 9 January 2007 6:03 p.m. To: firstname.lastname@example.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. > _______________________________________________ > email@example.com mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"