Stephen Smalley wrote: > http://pecl.php.net/package/selinux Thanks! > > In short, I was wondering if there was a way for a rename()d file to be > > subjected to a type transition as if a new file was created? (I tried a > > type_trans rule but to no avail.) Or any other way to deal with renaming > > files between variously contexted dirs? > > No. The best way of course is to create the file with the right > security context in the first place, whether explicitly or by uploading > it to the same parent directory as the final destination. That's what I do right now. I can do that because there's only one context. But in a web service your script isn't invoked until the file is already uploaded. So you can't pre-set the correct context and/or destination if you have two or more possibilities. > Alternatively the php scriptlet can use the selinux bindings to > manipulate the context, or you can configure restorecond(8) to watch > for the destination file and reset its security context as needed. Does restorecond handle recursive directory restoring yet? (Last time I tried it worked only on single files.) But yes, in principle a cron job with 'restorecon -R' is a way too. But all those solutions are 'dirty', because they need you to make an extra effort. There's already a huge infrastructure with type inheritance and transitions, as to make the labeling independent of the application; but the rename operation just spoils that and forces you back to square one, to explicitly care about your files' contexts. Is there a fundamental reason why this is so (and can't be changed)? Michal Svoboda
Attachment:
pgpupIe9SVDp6.pgp
Description: PGP signature