file permissions and user access

[Onur Bektas]

Hi,

If user has a full rwx access to its home directory   (and it is usually 
the case) then it "can" remove the files within the directory even if 
the user cannot read the content of file.
Solution to your problem  may be change the user home directory 
ownership  to root and   then set a sticky bit to user home directory 
(i.e, chmod 1775 $HOME) .After that, user can
only delete the file its the owner of file (like the case in /tmp) . A 
better solution is to  put configuration files other directory owned by 
root.

Regards,

Onur.


On 4/8/2010 12:05 PM, Erich Jenkins, Fuujin Group Ltd wrote:
> I've gone through the archives for the Jail list, and I'm not finding 
> anything specific to the issue we're experiencing. My apologies if 
> this is a known issue or if I've done something daft, but there 
> appears to be a file permission issue with jails.
>
> We have a large deployment of jailed systems, and an issue was brought 
> to my attention today that I hope very much is the result of a 
> misconfiguration or other mistake.
>
> Background:
>
> Environment is FreeBSD 7.0-REL and 8.0-REL
> Platforms include i386 (x86 Xeon), amd64 (Opteron) and sparc64 (Netra 
> X1's)
> Jail environment is a Complete jail, not an application jail
>
> Situation:
>
> A user managed to kill an apache process today, resulting in their 
> virtual web server (in a jail) going down. The user does not have root 
> privileges on this box, and is not a member of wheel. Upon inspection, 
> I found that the user had deleted a config file that was owned by root 
> (chmod 700). It appears they were not able to read the file, but they 
> were able to delete it which I confirmed with the user.
>
> Test:
>
> To verify what appeared to be happening, I created a file in the users 
> home directory (typed some garbage into a text file) owned by root 
> (700) and in the wheel group. I then logged into the users account via 
> ssh as that user. I attempted to su to root, which I could not (as 
> expected). I tried to read the file and could not (as expected). Then 
> I tried to delete the file. Bingo. File was gone.
>
> I also tried this via FTP using their account and the same thing 
> happened. I could delete the file, but could not transfer it, nor open 
> it.
>
> Any thoughts on this would be greatly appreciated. I've tried this in 
> the lab and on some production boxes, and this appears to affect 
> 7.0-REL and 8.0-REL (the only versions in the environment). This also 
> does not appear to be specific to any particular architecture as I 
> have tested on sparc64, amd64 and i386 boxes.
>


-- 
------
Onur BEKTAS
Sistem Yöneticisi / System Administrator
Teknik Destek Grubu 
TÜBITAK ULAKBIM

tel: +903122989367
fax: +903122989393 
----------------------------------