當一個可執(zhí)行文件已經(jīng)為write而open時，此時的可執(zhí)行文件是不允許被執(zhí)行的。反過來，一個文件正在執(zhí)行時，它也是不允許同時被write模式而open的。這個約束很好理解，因為文件執(zhí)行和文件被寫應該需要同步保護，因此內(nèi)核會保證這種同步。

　　那么內(nèi)核是如何實現(xiàn)該機制的呢?

　　Inode結點中包含一個數(shù)據(jù)項，叫做i_writecount,很明顯是用于記錄文件被寫的個數(shù)的，用于同步的，其類型也是atomic_t. 內(nèi)核中有兩個我們需要了解的函數(shù)，與write操作有關，分別是:

int get_write_access(struct inode * inode) {spin_lock(&inode->i_lock);if (atomic_read(&inode->i_writecount) < 0) {spin_unlock(&inode->i_lock);return -ETXTBSY;}atomic_inc(&inode->i_writecount);spin_unlock(&inode->i_lock);return 0; }int deny_write_access(struct file * file) {struct inode *inode = file->f_path.dentry->d_inode;spin_lock(&inode->i_lock);if (atomic_read(&inode->i_writecount) > 0) {//如果文件被打開了，返回失敗spin_unlock(&inode->i_lock);return -ETXTBSY;}atomic_dec(&inode->i_writecount); spin_unlock(&inode->i_lock); }

　　這兩個函數(shù)都很簡單，get_write_acess作用就和名稱一致，同樣deny_write_access也是。如果一個文件被執(zhí)行了，要保證它在執(zhí)行的過程中不能被寫，那么在開始執(zhí)行前應該調(diào)用deny_write_access 來關閉寫的權限。那就來檢查execve系統(tǒng)調(diào)用有沒有這么做。

　　Sys_execve中調(diào)用do_execve,然后又調(diào)用函數(shù)open_exec,看一下open_exec的代碼:

struct file *open_exec(const char *name) {struct file *file;int err;file = do_filp_open(AT_FDCWD, name,O_LARGEFILE | O_RDONLY | FMODE_EXEC, 0,MAY_EXEC | MAY_OPEN);if (IS_ERR(file))goto out;err = -EACCES;if (!S_ISREG(file->f_path.dentry->d_inode->i_mode))goto exit;if (file->f_path.mnt->mnt_flags & MNT_NOEXEC)goto exit;fsnotify_open(file->f_path.dentry);err = deny_write_access(file);//調(diào)用if (err)goto exit;out:return file;exit:fput(file);return ERR_PTR(err); }

　　明顯看到了deny_write_access的調(diào)用，和預想的完全一致。在open的調(diào)用里，應該有get_write_access的調(diào)用。在open調(diào)用相關的__dentry_open函數(shù)中就包含了對該函數(shù)的調(diào)用，

if (f->f_mode & FMODE_WRITE) {error = __get_file_write_access(inode, mnt);if (error)goto cleanup_file;if (!special_file(inode->i_mode))file_take_write(f); }

　　其中__get_file_write_access(inode, mnt)封裝了get_write_access.

　　那么內(nèi)核又是如何保證一個正在被寫的文件是不允許被執(zhí)行的呢?這個同樣也很簡單，當一個文件已經(jīng)為write而open時，它對應的inode的i_writecount會變成1，因此在執(zhí)行execve時同樣會調(diào)用deny_write_access 中讀取到i_writecount>0之后就會返回失敗，因此execve也就會失敗返回。

　　這里是寫文件與i_writecount相關的場景:
　　寫打開一個文件時，在函數(shù)dentry_open中:

if (f->f_mode & FMODE_WRITE) { error = get_write_access(inode); if (error) goto cleanup_file; }

　　當然在文件關閉時，會將i_writecount--；關閉時會執(zhí)行代碼:

if (file->f_mode & FMODE_WRITE) put_write_access(inode);

　　put_write_access 代碼很簡單:

static inline void put_write_access(struct inode * inode) { atomic_dec(&inode->i_writecount); }

　　于是乎自己寫了個簡單的代碼，一個空循環(huán)，文件在執(zhí)行的時候，在bash中，echo 111 >>可執(zhí)行文件，結果預期之中，返回失敗，并提示信息 text file busy.

　　那么該機制是否同樣適用于映射機制呢，在執(zhí)行可執(zhí)行文件時，會mmap一些關聯(lián)的動態(tài)鏈接庫，這些動態(tài)鏈接庫是否被mmap之后就不允許被寫以及正在寫時不允許mmap呢?這個是需要考慮的，因為它關系到安全的問題。因為庫文件也是可執(zhí)行的代碼，被篡改同樣會引起安全問題。

　　Mmap在調(diào)用mmap_region的函數(shù)里，有一個相關的檢查:

if (vm_flags & VM_DENYWRITE) { error = deny_write_access(file);if (error)goto free_vma;correct_wcount = 1; }

　　其中，mmap調(diào)用中的flags參數(shù)會被正確的賦值給vm_flags,對應關系是MAP_DENYWRIRE被設置了，那么VM_DENYWRITE就對應的也被設置。下面寫了個簡單的代碼，做一下測試:

#include <stdio.h> #include <sys/mman.h> #include <string.h> #include <errno.h> #include <fcntl.h> #include <unistd.h> int main() {int fd;void *src = NULL;fd = open("test.txt",O_RDONLY);if (fd != 0){if ((src = mmap(0,5,PROT_READ|PROT_EXEC ,MAP_PRIVATE| MAP_DENYWRITE,fd,0))== MAP_FAILED){printf("MMAP error\n");printf("%s\n",strerror(errno));}else{printf("%x\n",src);}}FILE * fd_t = fopen("test.txt","w");if( !fd_t){printf("open for write error\n");printf("%s\n",strerror(errno));return 0;}if (fwrite("0000",sizeof(char),4,fd_t) != 4){printf("fwrite error \n");}fclose(fd_t);close(fd);return 1; }

　　最后的test.txt被寫成了”0000”，很奇怪，貌似MAP_DENTWRITE不起作用了。于是man mmap查看，發(fā)現(xiàn):

　　MAP_DENYWRITE

　　This ?flag ?is ignored. ?(Long ago, it signaled that attempts to write to the underlying?file should fail with ETXTBUSY. But this was a source of denial-of-service attacks.)

　　原來這個標識在用戶層已經(jīng)不起作用了啊，而且還說明了原因，容易引起拒絕式服務攻擊。攻擊者惡意的將某些系統(tǒng)程序要寫的文件以MAP_DENYWRITE模式映射，會導致正常程序?qū)懳募　２贿^VM_DENYWRITE在內(nèi)核里還是有使用的，在mmap中還是有對deny_write_access的調(diào)用， 但是對它的調(diào)用已經(jīng)不是由mmap中的flag參數(shù)的MAP_DENYWRITE驅(qū)動的了。

　　那與可執(zhí)行文件相關的動態(tài)鏈接庫文件就悲劇了，大家都知道動態(tài)鏈接庫使用的也是mmap，這也導致動態(tài)鏈接庫在運行時可以被更改。其實我這就是為了確認這點。這也導致我需要自己寫同步控制代碼了。我們可以使用inode中的i_security以及file結構的f_secutiry變量來寫自己的同步邏輯，就是麻煩了不少，還要寫內(nèi)核模塊，哎，工作量又增加了啊。安全問題是個麻煩的問題...

轉(zhuǎn)載于:https://www.cnblogs.com/liushaodong/p/3381310.html

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的linux 可执行文件与写操作的同步问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。