<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    agapple

    BlogJava 首頁 新隨筆 聯系 聚合 管理
      13 Posts :: 1 Stories :: 1 Comments :: 0 Trackbacks

    2010年11月1日 #

         摘要: 背景     前段時間在工作中,包括一些代碼閱讀過程中,spring aop經常性的會看到cglib中的相關內容,包括BeanCopier,BulkBean,Enancher等內容,以前雖大致知道一些內容,原理是通過bytecode,但沒具體深入代碼研究,只知其所用不知其所以然,所以就特地花了半天多的工作時間研究了CGLIB的相關源碼,同時結合看了下 spring ...  閱讀全文
    posted @ 2010-11-01 22:24 agapple 閱讀(1316) | 評論 (0)編輯 收藏

    2010年10月23日 #

       最近在做offerdetail優化時,替換了數據庫驅動,從c3p0 0.9.1 -> dbcp 1.4,順便研究了下dbcp的自動重連的一套機制,也做一下分享,大家周知一下。

     

    數據庫鏈接 常見的問題:

    1. 數據庫意外重啟后,原先的數據庫連接池能自動廢棄老的無用的鏈接,建立新的數據庫鏈接

    2. 網絡異常中斷后,原先的建立的tcp鏈接,應該能進行自動切換。比如網站演習中的交換機重啟會導致網絡瞬斷

    3. 分布式數據庫中間件,比如cobar會定時的將空閑鏈接異常關閉,客戶端會出現半開的空閑鏈接。

     

    大致思考解決思路:

    1.      sql心跳檢查(主動式)

    2.      拿鏈接嘗試一下,發現處理失敗丟棄鏈接,探雷的請求會失敗幾個 (犧牲小我,完成大我的精神)

    3.      設置合理的空閑鏈接的超時時間,避免半開鏈接(懶模式,解決半開鏈接)

     

     

    下面我們來看看,在dbcp中是如何實現。

    sql心跳檢查

    sql validate配置

    <property name="testWhileIdle"><value>true</value></property>

    <property name="testOnBorrow"><value>false</value></property>

    <property name="testOnReturn"><value>false</value></property>

    <property name="validationQuery"><value>select sysdate from dual</value></property>

    <property name="validationQueryTimeout"><value>1</value></property>

    <property name="timeBetweenEvictionRunsMillis"><value>30000</value></property>

    <property name="numTestsPerEvictionRun"><value>16</value></property>

    參數說明

      

       dbcp是采用了commons-pool做為其連接池管理,testOnBorrow,testOnReturn, testWhileIdlepool是提供的幾種校驗機制,通過外部鉤子的方式回調dbcp的相關數據庫鏈接(validationQuery)校驗, dbcp相關外部鉤子類:PoolableConnectionFactory,繼承于common-pool PoolableObjectFactory , dbcp通過GenericObjectPool這一入口,進行連接池的borrow,return處理。

    具體參數描述:

       1. testOnBorrow : 顧明思義,就是在進行borrowObject進行處理時,對拿到的connection進行validateObject校驗

       2. testOnReturn : 顧明思義,就是在進行returnObject對返回的connection進行validateObject校驗,個人覺得對數據庫連接池的管理意義不大

       3. testWhileIdle : 關注的重點,GenericObjectPool中針對pool管理,起了一個異步Evict的TimerTask定時線程進行控制(可通過設置參數 timeBetweenEvictionRunsMillis>0),定時對線程池中的鏈接進行validateObject校驗,對無效的鏈接進行關閉后,會調用ensureMinIdle,適當建立鏈接保證最小的minIdle連接數。

       4. timeBetweenEvictionRunsMillis,設置的Evict線程的時間,單位ms,大于0才會開啟evict檢查線程

       5. validateQuery, 代表檢查的sql

       6. validateQueryTimeout, 代表在執行檢查時,通過statement設置,statement.setQueryTimeout(validationQueryTimeout)

       7. numTestsPerEvictionRun,代表每次檢查鏈接的數量,建議設置和maxActive一樣大,這樣每次可以有效檢查所有的鏈接.

    Sql心跳檢查幾點思考:

    1.性能問題。

    目前網站的應用大部分的瓶頸還是在I/O這一塊,大部分的I/O還是在數據庫的這一層面上,每一個請求可能會調用10來次SQL查詢,如果不走事務,一個請求會重復獲取鏈接,如果每次獲取鏈接,比如在testOnBorrow都進行validateObject,性能開銷不是很能接受,可以假定一次SQL操作消毫0.5~1ms(一般走了網絡請求基本就這數)

    2.成本和收益

    網站異常數據庫重啟,網絡異常斷開的頻率是非常低的,一般也就在數據庫升級,演習維護時才會進行,而且一般也是選在晚上,訪問量相對比較低的請求,而且一般會有人員值班關注,所以異步的validateObject是可以接受,但一個前提需要確保能保證在一個合理的時間段內,數據庫能完成自動重聯。

     

    請求探雷

    相關配置

    dbcp自身默認支持,不需要配置

    原理描述

    common-pools通過borrowObject , returnObject完成連接的獲取和釋放,正常的情況是一次請求中borrow和return是一對的,有借就有還。

    但在準備returnObject時,dbcp會做一件事,就是看看這個object是否已經是壞了的,如果壞了就直接丟了,就直接給丟棄了。

     

    代碼層面:

    1. 在dbcp中PoolingDataSource(實現DataSource接口)調用 PoolableConnection(dbcp connnection相關的pool delegate操作)進行相應關閉時,會檢查_conn.isClosed(),針對DataSource如果isClosed返回為 true的則不調用returnObject,直接丟棄了鏈接。

    2. _conn.isClosed()是否保險,從jdk的api描述中: A connection is closed if the method close has been called on it or if certain fatal errors have occurred. 里面提供兩種情況,一種就是被調用了closed方法,另一種就是出現一些異常,說的比較含糊。

     

    空閑鏈接檢查

    相關配置

    <property name="minEvictableIdleTimeMillis"><value>18000000</value></property>

    <property name="removeAbandoned"><value>true</value></property> 

    <property name="removeAbandonedTimeout"><value>180</value></property>

    參數說明

    1.minEvictableIdleTimeMillis dbcp默認是30分,需要開啟異步線程Evict,否則不生效。原理很簡單,就是通過一個異步線程,每次檢查connnection上一次使用的時間戳,看看是否已經超過這個timeout時間設置。

    2. removeAbandoned , removeAbandonedTimeout,主要是用于在出現鏈接緊張時候,會掃描一些鏈接未超過removeAbandonedTimeout時間還未被釋放,會主動的關閉該鏈接。

    適用情況

    1. 我們使用的cobar后端會有定時關閉空閑鏈接的操作,默認的空閑鏈接timeout時間為1小時,和其他oracle , mysql各不相同,所以設置好這個空閑鏈接的timeout時間還是挺重要.

     

    2. 一般會是幾種情況出現需要removeAbandoned: 

    * 代碼未在finally釋放connection , 不過我們都用sqlmapClientTemplate,底層都有鏈接釋放的過程

    * 遇到數據庫死鎖。以前遇到過后端存儲過程做了鎖表操作,導致前臺集群中連接池全都被block住,后續的業務處理因為拿不到鏈接所有都處理失敗了。

     

     

    聊聊c3p0配置

    還有我們配置的c3p0所謂的自動重連的3個參數,

    <prop key="acquireRetryAttempts">30</prop>

        <prop key="acquireRetryDelay">1000</prop>

        <prop key="breakAfterAcquireFailure">false</prop>

     

    個人覺得就是一個誤導,這幾個配置只是在從連接池獲取鏈接時,獲取失敗多嘗試幾次,因為我們從pool從獲取鏈接最多只會等待固定timeout時間。

    如果要達到自動重連的效果,必須要c3p0支持請求探雷或者是sql心跳檢查功能,能自動的剔除無效的鏈接?!?/span>

    可見c3p0官方文檔描述:http://www.mchange.com/projects/c3p0/index.html#configuring_recovery

     

    最后:

    Dbcp將是我們以后數據庫驅動選擇的趨勢,最后我們如何選擇如何自動重連,這個也得根據我們的應用場景而定。比如只讀的web系統,后臺業務系統,任務系統可能處理方式就不同。

    只讀Web系統:可采取請求探雷的策略,也就失敗連接池個數的請求,失敗了頁面刷新一次就好。

    后臺業務系統:一般業務都涉及數據庫的寫操作,很多數據不可重入,一次處理失敗后就只能靠手工干預處理。這時候得考慮是否需要使用sql心跳檢查,比如testOnBorrow或者testWhileIdle.

    posted @ 2010-10-23 01:01 agapple 閱讀(959) | 評論 (0)編輯 收藏

    2009年2月15日 #

         摘要:   閱讀全文
    posted @ 2009-02-15 21:47 agapple 閱讀(6397) | 評論 (1)編輯 收藏

    2009年1月14日 #

    1. 下載rsync  (http://rsync.samba.org/)

    安裝:
    ./configure
    make
    make install

    2. 開啟rsync服務,修改/etc/xinetd.d/rsync
    disable = no # replace <yes>
    重啟xinetd 服務
    service xinetd restart


    3. 配置server端,/etc/rsyncd.conf
    # touch rsyncd.conf
    # vi rsyncd.conf
    uid = ljh  #表示以什么用戶運行,注意必須確保該用戶有對模塊的讀寫權限
    gid = ljh
    use chroot = false
    max connectionts = 6
    read only = no
    pid file = /home/ljh/server/rsync/rsynnd.pid
    lock file = /home/ljh/server/rsync/rsyncd.lock
    log file = /home/ljh/server/rsync/rsyncd.log
    [test]
    comment = test
    path = /home/ljh/server/rsync/data/test
    ignore error
    list = true
    #auth users = ljh
    #secrets file = /home/ljh/server/rsync/passwd/rsyncd.passwd

     

    配置參數介紹
    comment
    給模塊指定一個描述,該描述連同模塊名在客戶連接得到模塊列表時顯示給客戶。默認沒有描述定義。
    path
    指定該模塊的供備份的目錄樹路徑,該參數是必須指定的。
    use chroot
    如 果"use chroot"指定為true,那么rsync在傳輸文件以前首先chroot到path參數所指定的目錄下。這樣做的原因是實現額外的安全防護,但是缺點是需要以roots權限,并且不能備份指向外部的符號連接所指向的目錄文件。默認情況下chroot值為true。
    uid
    該選項指定當該模塊傳輸文件時守護進程應該具有的uid,配合gid選項使用可以確定哪些可以訪問怎么樣的文件權限,默認值是"nobody"。
    gid
    該選項指定當該模塊傳輸文件時守護進程應該具有的gid。默認值為"nobody"。
    max connections
    指定該模塊的最大并發連接數量以保護服務器,超過限制的連接請求將被告知隨后再試。默認值是0,也就是沒有限制。
    list
    該選項設定當客戶請求可以使用的模塊列表時,該模塊是否應該被列出。如果設置該選項為false,可以創建隱藏的模塊。默認值是true。
    read only
    該選項設定是否允許客戶上載文件。如果為true那么任何上載請求都會失敗,如果為false并且服務器目錄讀寫權限允許那么上載是允許的。默認值為true。
    exclude
    用 來指定多個由空格隔開的多個文件或目錄(相對路徑),并將其添加到exclude列表中。這等同于在客戶端命令中使用--exclude來指定模式,一個 模塊只能指定一個exclude選項。但是需要注意的一點是該選項有一定的安全性問題,客戶很有可能繞過exclude列表,如果希望確保特定的文件不能 被訪問,那就最好結合uid/gid選項一起使用。
    exclude from [file]
    指定一個包含exclude模式的定義的文件名,服務器從該文件中讀取exclude列表定義。
    include
    用來指定不排除符合要求的文件或目錄。這等同于在客戶端命令中使用--include來指定模式,結合include和exclude可以定義復雜的exclude/include規則。
    include from [file]
    指定一個包含include模式的定義的文件名,服務器從該文件中讀取include列表定義。
    auth users
    該選項指定由空格或逗號分隔的用戶名列表,只有這些用戶才允許連接該模塊。這里的用戶和系統用戶沒有任何關系。如果"auth users"被設置,那么客戶端發出對該模塊的連接請求以后會被rsync請求challenged進行驗證身份這里使用的 challenge/response認證協議。用戶的名和密碼以明文方式存放在"secrets file"選項指定的文件中。默認情況下無需密碼就可以連接模塊(也就是匿名方式)。
    secrets file
    該選項指定一個包含定義用戶名:密碼對的文件。只有在"auth users"被定義時,該文件才有作用。文件每行包含一個username:passwd對。一般來說密碼最好不要超過8個字符。沒有默認的 secures file名,需要限式指定一個(例如:/etc/rsyncd.passwd)。注意:該文件的權限一定要是600,否則客戶端將不能連接服務器
    strict modes
    該選項指定是否監測密碼文件的權限,如果該選項值為true那么密碼文件只能被rsync服務器運行身份的用戶訪問,其他任何用戶不可以訪問該文件。默認值為true。
    hosts allow
    該選項指定哪些IP的客戶允許連接該模塊。客戶模式定義可以是以下形式:單個IP地址,例如:192.167.0.1
    hosts deny
    指定不允許連接rsync服務器的機器,可以使用hosts allow的定義方式來進行定義。默認是沒有hosts deny定義。
    ignore errors
    指定rsyncd在判斷是否運行傳輸時的刪除操作時忽略server上的IO錯誤,一般來說rsync在出現IO錯誤時將將跳過--delete操作,以防止因為暫時的資源不足或其它IO錯誤導致的嚴重問題。
    lock file
    指定支持max connections參數的鎖文件,默認值是/var/run/rsyncd.lock。
    timeout
    通過該選項可以覆蓋客戶指定的IP超時時間。通過該選項可以確保rsync服務器不會永遠等待一個崩潰的客戶端。超時單位為秒鐘,0表示沒有超時定義,這也是默認值。對于匿名rsync服務器來說,一個理想的數字是600。
    dont compress
    用來指定那些不進行壓縮處理再傳輸的文件,默認值是*.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz

     

    4. 客戶端配置
    訪問remote rsync列表
    rsync rsync://10.0.64.162/test
    簡單的執行同步命令
    sync -auv --delete --password-file=/home/admin2/soft/rsync/passwd/rsyncd.passwd ~/rysnc/* ljh@10.0.64.162::test

    比較實際的例子:
    echo "hello" > /tmp/password.txt ;chmod 600 /tmp/password.txt
    cp /home/ewalletbops/fatrix/crm/* /home/ewalletbops/fatrix/putxml/search
    rsync -azv /home/ewalletbops/bops-daemon/bin/adxml/search/ /home/ewalletbops/fatrix/putxml/search
    rsync -auv --delete --password-file=/tmp/password.txt /home/ewalletbops/fatrix/putxml/search yangzhen@127.0.0.1::everest/adxml
    rm /tmp/password.txt


     

    選項說明
    -v, --verbose 詳細模式輸出
    -q, --quiet 精簡輸出模式
    -c, --checksum 打開校驗開關,強制對文件傳輸進行校驗
    -a, --archive 歸檔模式,表示以遞歸方式傳輸文件,并保持所有文件屬性,等于-rlptgoD
    -r, --recursive 對子目錄以遞歸模式處理
    -R, --relative 使用相對路徑信息
    -b, --backup 創建備份,也就是對于目的已經存在有同樣的文件名時,將老的文件重新命名為~filename??梢允褂?-suffix選項來指定不同的備份文件前綴。
    --backup-dir 將備份文件(如~filename)存放在在目錄下。
    -suffix=SUFFIX 定義備份文件前綴
    -u, --update 僅僅進行更新,也就是跳過所有已經存在于DST,并且文件時間晚于要備份的文件。(不覆蓋更新的文件)
    -l, --links 保留軟鏈結
    -L, --copy-links 想對待常規文件一樣處理軟鏈結
    --copy-unsafe-links 僅僅拷貝指向SRC路徑目錄樹以外的鏈結
    --safe-links 忽略指向SRC路徑目錄樹以外的鏈結
    -H, --hard-links 保留硬鏈結
    -p, --perms 保持文件權限
    -o, --owner 保持文件屬主信息
    -g, --group 保持文件屬組信息
    -D, --devices 保持設備文件信息
    -t, --times 保持文件時間信息
    -S, --sparse 對稀疏文件進行特殊處理以節省DST的空間
    -n, --dry-run現實哪些文件將被傳輸
    -W, --whole-file 拷貝文件,不進行增量檢測
    -x, --one-file-system 不要跨越文件系統邊界
    -B, --block-size=SIZE 檢驗算法使用的塊尺寸,默認是700字節
    -e, --rsh=COMMAND 指定替代rsh的shell程序
    --rsync-path=PATH 指定遠程服務器上的rsync命令所在路徑信息
    -C, --cvs-exclude 使用和CVS一樣的方法自動忽略文件,用來排除那些不希望傳輸的文件
    --existing 僅僅更新那些已經存在于DST的文件,而不備份那些新創建的文件
    --delete 刪除那些DST中SRC沒有的文件
    --delete-excluded 同樣刪除接收端那些被該選項指定排除的文件
    --delete-after 傳輸結束以后再刪除
    --ignore-errors 及時出現IO錯誤也進行刪除
    --max-delete=NUM 最多刪除NUM個文件
    --partial 保留那些因故沒有完全傳輸的文件,以是加快隨后的再次傳輸
    --force 強制刪除目錄,即使不為空
    --numeric-ids 不將數字的用戶和組ID匹配為用戶名和組名
    --timeout=TIME IP超時時間,單位為秒
    -I, --ignore-times 不跳過那些有同樣的時間和長度的文件
    --size-only 當決定是否要備份文件時,僅僅察看文件大小而不考慮文件時間
    --modify-window=NUM 決定文件是否時間相同時使用的時間戳窗口,默認為0
    -T --temp-dir=DIR 在DIR中創建臨時文件
    --compare-dest=DIR 同樣比較DIR中的文件來決定是否需要備份
    -P 等同于 --partial
    --progress 顯示備份過程
    -z, --compress 對備份的文件在傳輸時進行壓縮處理
    --exclude=PATTERN 指定排除不需要傳輸的文件模式
    --include=PATTERN 指定不排除而需要傳輸的文件模式
    --exclude-from=FILE 排除FILE中指定模式的文件
    --include-from=FILE 不排除FILE指定模式匹配的文件
    --version 打印版本信息
    --address 綁定到特定的地址
    --config=FILE 指定其他的配置文件,不使用默認的rsyncd.conf文件
    --port=PORT 指定其他的rsync服務端口
    --blocking-io 對遠程shell使用阻塞IO
    --stats 給出某些文件的傳輸狀態
    --progress 在傳輸時現實傳輸過程
    --log-format=formAT 指定日志文件格式
    --password-file=FILE 從FILE中得到密碼
    --bwlimit=KBPS 限制I/O帶寬,KBytes per second
    -h, --help 顯示幫助信息

     

     

     

     

     

     

     

     

     

    posted @ 2009-01-14 14:12 agapple 閱讀(739) | 評論 (0)編輯 收藏

    2008年11月7日 #

         摘要:   閱讀全文
    posted @ 2008-11-07 20:48 agapple 閱讀(2600) | 評論 (0)編輯 收藏

    2008年11月3日 #

         摘要:   閱讀全文
    posted @ 2008-11-03 20:13 agapple 閱讀(425) | 評論 (0)編輯 收藏

    2008年10月31日 #

    Tip1

    1.在 JAVA_HOME/jre/lib/fonts/ 下建立個目錄 fallback
    2.在 fallback 里弄個中文字體最簡單ln一下就好了
    比如:

    ln -s /usr/share/fonts/truetype/arphic/uming.ttf  $JAVA_HOME/jre/lib/fonts/fallback/

    Tip2

    問題描述:Java 應用程序的中文無法顯示,呈現方塊狀。

      原因分析:Java 應用程序無法找到可供顯示中文的字體。

      解決方案:首先,確保系統里安裝了 JDK 1.5.0_06,如果安裝的是 JRE 1.5.0_06,那么卸掉 JRE,再安裝 JDK。然后下載 fireflysung 1.3.0, 解壓后將其中的 ttf 文件丟到系統字體目錄/usr/share/fonts,再用 fc-cache -f -v 跑一遍,讓系統知道這個字體。最后,就是轉到 JDK 安裝目錄的jre/lib/fonts 中,使用下面的命令來完成。

      mkdir fallback
      cd fallback
      ln -s /usr/share/fonts/fireflysung.ttf
      mkfontdir
      mkfontscale
    posted @ 2008-10-31 16:31 agapple 閱讀(466) | 評論 (0)編輯 收藏

    由于用戶在UNIX下經常會遇到SUID、SGID的概念,而且SUID和SGID涉及到系統安全,所以用戶也比較關心這個問題。關于 SUID、SGID的問題也經常有人提問,但回答的人一般答得不夠詳細,加上曾經回答過兩個網友的問題,還查了一些資料,決定整理成本文,以供大家參考。 限于本人的水平問題,文章中如果有不當之處,請廣大網友指正。

      一、UNIX下關于文件權限的表示方法和解析

      SUID 是 Set User ID, SGID 是 Set Group ID的意思。

      UNIX下可以用ls -l 命令來看到文件的權限。用ls命令所得到的表示法的格式是類似這樣的:-rwxr-xr-x 。下面解析一下格式所表示的意思。這種表示方法一共有十位:

      9 8 7 6 5 4 3 2 1 0

      - r w x r - x r - x

      第9位表示文件類型,可以為p、d、l、s、c、b和-:

      p表示命名管道文件

      d表示目錄文件

      l表示符號連接文件

      -表示普通文件

      s表示socket文件

      c表示字符設備文件

      b表示塊設備文件

      第8-6位、5-3位、2-0位分別表示文件所有者的權限,同組用戶的權限,其他用戶的權限,其形式為rwx:

      r表示可讀,可以讀出文件的內容

      w表示可寫,可以修改文件的內容

      x表示可執行,可運行這個程序

      沒有權限的位置用-表示

      例子:

      ls -l myfile顯示為:

      rwxr-x-- 1 foo staff 7734 Apr 05 17:07 myfile

      表示文件myfile是普通文件,文件的所有者是foo用戶,而foo用戶屬于staff組,文件只有1個硬連接,長度是7734個字節,最后修改時間4月5日17:07。

      所有者foo對文件有讀寫執行權限,staff組的成員對文件有讀和執行權限,其他的用戶對這個文件沒有權限。

      如果一個文件被設置了SUID或SGID位,會分別表現在所有者或同組用戶的權限的可執行位上。例如:

      1、-rwsr-xr-x 表示SUID和所有者權限中可執行位被設置

      2、rwSrr- 表示SUID被設置,但所有者權限中可執行位沒有被設置

      3、-rwxr-sr-x 表示SGID和同組用戶權限中可執行位被設置

      4、rw-r-Sr- 表示SGID被設置,但同組用戶權限中可執行位沒有被社

      其實在UNIX的實現中,文件權限用12個二進制位表示,如果該位置上的值是

      1,表示有相應的權限:

      11 10 9 8 7 6 5 4 3 2 1 0

      S G T r w x r w x r w x

      第11位為SUID位,第10位為SGID位,第9位為sticky位,第8-0位對應于上面的三組rwx位。

      11 10 9 8 7 6 5 4 3 2 1 0

      上面的-rwsr-xr-x的值為: 1 0 0 1 1 1 1 0 1 1 0 1

      rw-r-Sr-的值為: 0 1 0 1 1 0 1 0 0 1 0 0

      給文件加SUID和SUID的命令如下:

      chmod u+s filename 設置SUID位

      chmod u-s filename 去掉SUID設置

      chmod g+s filename 設置SGID位

      chmod g-s filename 去掉SGID設置

      另外一種方法是chmod命令用八進制表示方法的設置。如果明白了前面的12位權限表示法也很簡單。

      二、SUID和SGID的詳細解析

      由于SUID和SGID是在執行程序(程序的可執行位被設置)時起作用,而可執行位只對普通文件和目錄文件有意義,所以設置其他種類文件的SUID和SGID位是沒有多大意義的。

      首先講普通文件的SUID和SGID的作用。例子:

      如果普通文件myfile是屬于foo用戶的,是可執行的,現在沒設SUID位,ls命令顯示如下:

      -rwxr-xr-x 1 foo staff 7734 Apr 05 17:07 myfile任何用戶都可以執行這個程序。UNIX的內核是根據什么來確定一個進程對資源的訪問權限的呢?是這個進程的運行用戶的(有效)ID,包括 user id和group id。用戶可以用id命令來查到自己的或其他用戶的user id和group id。

      除了一般的user id 和group id外,還有兩個稱之為effective 的id,就是有效id,上面的四個id表示為:uid,gid,euid,egid。內核主要是根據euid和egid來確定進程對資源的訪問權限。

      一個進程如果沒有SUID或SGID位,則euid=uid egid=gid,分別是運行這個程序的用戶的uid和gid。例如kevin用戶的uid和gid分別為204和202,foo用戶的uid和gid為 200,201,kevin運行myfile程序形成的進程的euid=uid=204,egid=gid=202,內核根據這些值來判斷進程對資源訪問 的限制,其實就是kevin用戶對資源訪問的權限,和foo沒關系。

      如果一個程序設置了SUID,則euid和egid變成被運行的程序的所有者的uid和gid,例如kevin用戶運行myfile,euid=200,egid=201,uid=204,gid=202,則這個進程具有它的屬主foo的資源訪問權限。

      SUID的作用就是這樣:讓本來沒有相應權限的用戶運行這個程序時,可以訪問他沒有權限訪問的資源。passwd就是一個很鮮明的例子。

      SUID的優先級比SGID高,當一個可執行程序設置了SUID,則SGID會自動變成相應的egid。

      下面討論一個例子:

      UNIX系統有一個/dev/kmem的設備文件,是一個字符設備文件,里面存儲了核心程序要訪問的數據,包括用戶的口令。所以這個文件不能給一般的用戶讀寫,權限設為:cr-r---- 1 root system 2, 1 May 25 1998 kmem

      但ps等程序要讀這個文件,而ps的權限設置如下:

      -r-xr-sr-x 1 bin system 59346 Apr 05 1998 ps

      這是一個設置了SGID的程序,而ps的用戶是bin,不是root,所以不能設置SUID來訪問kmem,但大家注意了,bin和root 都屬于system組,而且ps設置了SGID,一般用戶執行ps,就會獲得system組用戶的權限,而文件kmem的同組用戶的權限是可讀,所以一般 用戶執行ps就沒問題了。但有些人說,為什么不把ps程序設置為root用戶的程序,然后設置SUID位,不也行嗎?這的確可以解決問題,但實際中為什么 不這樣做呢?因為SGID的風險比SUID小得多,所以出于系統安全的考慮,應該盡量用SGID代替SUID的程序,如果可能的話。下面來說明一下 SGID對目錄的影響。SUID對目錄沒有影響。如果一個目錄設置了SGID位,那么如果任何一個用戶對這個目錄有寫權限的話,他在這個目錄所建立的文件 的組都會自動轉為這個目錄的屬主所在的組,而文件所有者不變,還是屬于建立這個文件的用戶。

      三、關于SUID和SGID的編程

      和SUID和SGID編程比較密切相關的有以下的頭文件和函數:

      #include

      #include

      uid_t getuid(void);

      uid_t geteuid(void);

      gid_t getgid (void);

      gid_t getegid (void);

      int setuid (uid_t UID);

      int setruid (uid_t RUID);

      int seteuid (uid_t EUID);

      int setreuid (uid_t RUID,uid_t EUID);

      int setgid (gid_t GID);

      int setrgid (gid_t RGID);

      int setegid (git_t EGID);

      int setregid (gid_t RGID, gid_t EGID);

      具體這些函數的說明在這里就不詳細列出來了,要用到的可以用man查。

      SUID/SGID :

      假如你有文件a.txt

      #ls -l a.txt

      -rwxrwxrwx

      #chmod 4777 a.txt

      -rwsrwxrwx ======>注意s位置

      #chmod 2777 a.txt

      -rwxrwsrwx ======>注意s位置

      #chmod 7777 a.txt

      -rwsrwxswt ======>出現了t,t的作用在內存中盡量保存a.txt,節省系統再加載的時間.

      現在再看前面設置 SUID/SGID作用:

      #cd /sbin

      #./lsusb

      ...

      #su aaa(普通用戶)

      $./lsusb

      ...

      是不是現在顯示出錯?

      $su

      #chmod 4755 lsusb

      #su aaa

      $./lsusb

      ... 現在明白了嗎?本來是只有root用戶才能執行的命令,加了SUID后,普通用戶就可以像root一樣的用,權限提升了。上面是對于文件來說的,對于目錄也差不多!

      目錄的S屬性使得在該目錄下創建的任何文件及子目錄屬于該目錄所擁有的組,目錄的T屬性使得該目錄的所有者及root才能刪除該目錄。還有對 于s與S,設置SUID/SGID需要有運行權限,否則用ls -l后就會看到S,證明你所設置的SUID/SGID沒有起作用。

      Why we need suid,how do we use suid?

      r -- 讀訪問

      w -- 寫訪問

      x -- 執行許可

      s -- SUID/SGID

      t -- sticky位

      那么 suid/sgid是做什么的? 為什么會有suid位呢?

      要想明白這個,先讓我們看個問題:如果讓每個用戶更改自己的密碼?

      用戶修改密碼,是通過運行命令passwd來實現的。最終必須要修改/etc/passwd文件,而passwd的文件的屬性是:

      #ls -l /etc/passwd

      rw-rr- 1 root root 2520 Jul 12 18:25 passwd

      我們可以看到passwd文件只有對于root用戶是可寫的,而對于所有的他用戶來說都是沒有寫權限的。 那么一個普通的用戶如何能夠通過運行passwd命令修改這個passwd文件呢?

      為了解決這個問題,SUID/SGID便應運而生。而且AT&T對它申請了專利。 呵呵。

      SUID和SGID是如何解決這個問題呢?

      首先,我們要知道一點:進程在運行的時候,有一些屬性,其中包括 實際用戶ID,實際組ID,有效用戶ID,有效組ID等。 實際用戶ID和實際組ID標識我們是誰,誰在運行這個程序,一般這2個字段在登陸時決定,在一個登陸會話期間, 這些值基本上不改變。

      而有效用戶ID和有效組ID則決定了進程在運行時的權限。內核在決定進程是否有文件存取權限時,是采用了進程的有效用戶ID來進行判斷的。

      知道了這點,我們來看看SUID的解決途徑:

      當一個程序設置了為SUID位時,內核就知道了運行這個程序的時候,應該認為是文件的所有者在運行這個程序。即該程序運行的時候,有效用戶ID是該程序的所有者。舉個例子:

      [root@sgrid5 bin]# ls -l passwd

      -r-s-s-x 1 root root 16336 Feb 14 2003 passwd

      雖然你以test登陸系統,但是當你輸入passwd命令來更改密碼的時候,由于passwd設置了SUID位,因此雖然進程的實際用戶ID 是test對應的ID,但是進程的有效用戶ID則是passwd文件的所有者root的ID,因此可以修改/etc/passwd文件。

      讓我們看另外一個例子。

      ping命令應用廣泛,可以測試網絡是否連接正常。ping在運行中是采用了ICMP協議,需要發送ICMP報文。但是只有root用戶才能建立ICMP報文,如何解決這個問題呢?同樣,也是通過SUID位來解決。

      [root@sgrid5 bin]# ls -l /bin/ping

      -rwsr-sr-x 1 root root 28628 Jan 25 2003 /bin/ping

      我們可以測試一下,如果去掉ping的SUID位,再用普通用戶去運行命令,看會怎么樣。

      [root@sgrid5 bin]#chmod u-s /bin/ping

      [root@sgrid5 bin]# ls -l ping

      -rwxr-xr-x 1 root root 28628 Jan 25 2003 ping

      [root@sgrid5 bin]#su test

      [test@sgrid5 bin]$ ping byhh.net

      ping: icmp open socket: Operation not permitted

      SUID雖然很好了解決了一些問題,但是同時也會帶來一些安全隱患。

      因為設置了 SUID 位的程序如果被攻擊(通過緩沖區溢出等方面),那么hacker就可以拿到root權限。

      因此在安全方面特別要注意那些設置了SUID的程序。

      通過以下的命令可以找到系統上所有的設置了suid的文件:

      [root@sgrid5 /]# find / -perm -04000 -type f -ls

      對于這里為什么是4000,大家可以看一下前面的st_mode的各bit的意義就明白了。

      在這些設置了suid的程序里,如果用不上的,就最好取消該程序的suid位。


    總結:
    1.Set UID:當文件系統的"所有者權限組合"的可執行位被s(即rws------)取代時,構成特殊權限規定Set UID,簡稱SUID。僅對系統中的二進制可執行文件設置有效,而且不可對Shell Script施加設置。
    2.Set GID:當所有者所在的用戶組(group)的權限組合中可執行位被s所取代時(例如--rws--),便構成Set GID的權限設置。SGID可以針對二進制文件或目錄進行設置。
    3.Sticky Bit:當文件系統"其他(others)"的權限組合中可執行位被t所取代時(例如------rwt),便構成Sticky Bit的權限設置。它只對目錄有效。

    SUID和SGID,主要作用是用于當非某個文件的所有者(或組)執行(或操作目錄)文件時,可以暫時獲得該文件所有者的權限。
    SBIT的作用在于訪問控制,當它對某個目錄設置此屬性后,該目錄下的所有文件,即使其它人有w屬性,都不得對其更名、移動、刪除。

    設置方法:
    如果你已經掌握了用(八進制)數字來表示權限的規則,再結合chmod命令進行設置就很簡單了。以下是SUID/SGID/Sticky Bit約定對應的八進制數值:
    SUID = 4
    SGID = 2
    SBIT = 1
    設置時我們把表示特殊權限的數字放在其他三位數字權限的前面。

    posted @ 2008-10-31 16:22 agapple 閱讀(314) | 評論 (0)編輯 收藏

    官方描述:http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html

    The META-INF directory

    The following files/directories in the META-INF directory are recognized and interpreted by the Java 2 Platform to configure applications, extensions, class loaders and services:
    • MANIFEST.MF
    The manifest file that is used to define extension and package related data.
    • INDEX.LIST
    This file is generated by the new "-i" option of the jar tool, which contains location information for packages defined in an application or extension.  It is part of the JarIndex implementation and used by class loaders to speed up their class loading process.
    • x.SF
    The signature file for the JAR file.  'x' stands for the base file name.
    • x.DSA
    The signature block file associated with the signature file with the same base file name. This file stores the digital signature of the corresponding signature file.
    • services/
    This directory stores all the service provider configuration files.

    這里指出了jar包的典型的目錄結構。簡單翻譯:

    META-INF目錄中的下列文件和目錄獲得Java 2平臺的認可與解釋,用來配置應用程序、擴展程序、類加載器和服務:
    • MANIFEST.MF:清單文件,用來定義與擴展和數據包相關的數據。
    • INDEX.LIST:這個文件由JAR工具的新“-i”選項生成,其中包含在一個應用程序或擴展中定義的數據包的地址信息。它是JarIndex的一部分,被類加載器用來加速類加載過程。
    • x.SF:JAR文件的簽名文件。x代表基礎文件名。
    • x.DSA:這個簽名塊文件與同名基礎簽名文件有關。此文件存儲對應簽名文件的數字簽名。
    • services/:這個目錄存儲所有服務提供程序配置文件。

    Service Provider

    Overview

    Files in the META-INF/services directory are service provider configuration files. A service is a well-known set of interfaces and (usually abstract) classes. A service provider is a specific implementation of a service. The classes in a provider typically implement the interfaces and subclass the classes defined in the service itself. Service providers may be installed in an implementation of the Java platform in the form of extensions, that is, jar files placed into any of the usual extension directories. Providers may also be made available by adding them to the applet or application class path or by some other platform-specific means.

    A service is represented by an abstract class. A provider of a given service contains one or more concrete classes that extend this service class with data and code specific to the provider. This provider class will typically not be the entire provider itself but rather a proxy that contains enough information to decide whether the provider is able to satisfy a particular request together with code that can create the actual provider on demand. The details of provider classes tend to be highly service-specific; no single class or interface could possibly unify them, so no such class has been defined. The only requirement enforced here is that provider classes must have a zero-argument constructor so that they may be instantiated during lookup.
     

    Provider-Configuration File

    A service provider identifies itself by placing a provider-configuration file in the resource directory META-INF/services. The file's name should consist of the fully-qualified name of the abstract service class. The file should contain a newline-separated list of unique concrete provider-class names. Space and tab characters, as well as blank lines, are ignored. The comment character is '#' (0x23); on each line all characters following the first comment character are ignored. The file must be encoded in UTF-8.
     

    Example

    Suppose we have a service class named java.io.spi.CharCodec. It has two abstract methods:

        public abstract CharEncoder getEncoder(String encodingName);
      public abstract CharDecoder getDecoder(String encodingName);

    Each method returns an appropriate object or null if it cannot translate the given encoding. Typical CharCodec providers will support more than one encoding.

    If sun.io.StandardCodec is a provider of the CharCodec service then its jar file would contain the file META-INF/services/java.io.spi.CharCodec. This file would contain the single line:

       sun.io.StandardCodec    # Standard codecs for the platform

    To locate an encoder for a given encoding name, the internal I/O code would do something like this:

       CharEncoder getEncoder(String encodingName) {
           Iterator ps = Service.providers(CharCodec.class);
           while (ps.hasNext()) {
               CharCodec cc = (CharCodec)ps.next();
               CharEncoder ce = cc.getEncoder(encodingName);
               if (ce != null)
                   return ce;
           }
           return null;
       }
     

    The provider-lookup mechanism always executes in the security context of the caller. Trusted system code should typically invoke the methods in this class from within a privileged security context.


    介紹:

    在META-INF/services目錄下保存的是service provider的配置文件。 服務在應用中會是一個接口(更多的是抽象類)。
    一個類服務器提供者實現了一個服務類。這類的服務提供類可以以擴展的形式發布到平臺上。所以,jar文件引入了擴展目錄,同樣你也可以將服務提供者加入classpath提供訪問。

    服務都是表現為一個積累,而一個服務提供者通常是集成或實現了服務定義類。服務提供類通常不會像代理類一樣為了正常提供服務而包含了請求者的許多信息。服務提供類一般傾向于高集成。
    對這類服務提供類的唯一強制性要求就是必須有一個無參的構造函數。

    provider 配置文件
    META-INF/services目錄作為provider配置文件的存放路徑。provider配置文件中必須是全類名(包含package)。配置文件可以存在space tab 換行等字符,#作為注釋。
    注意:provider配置文件必須是以UTF-8編碼。

     


    總結:
          service provider機制為程序的動態擴展提供了契機,在應用中你可以針對接口編程,通過RTTI技術可以比較完美的解決程序之間的耦合性。相比于spring DIP機制,這也是一個不錯的嘗試,至少它不需要耦合spring包。
    posted @ 2008-10-31 11:32 agapple 閱讀(770) | 評論 (0)編輯 收藏

    2008年10月30日 #

    TitleLABEL=/                 /                       ext3    defaults        1 1
    LABEL=/boot             /boot                   ext3    defaults        1 2
    none                    /dev/pts                devpts  gid=5,mode=620  0 0
    LABEL=/home             /home                   ext3    defaults        1 2
    none                    /proc                   proc    defaults        0 0
    none                    /dev/shm                tmpfs   defaults        0 0
    LABEL=/tmp              /tmp                    ext3    defaults        1 2
    LABEL=/usr              /usr                    ext3    defaults        1 2
    LABEL=/var              /var                    ext3    defaults        1 2
    /dev/sda6               swap                    swap    defaults        0 0
    /dev/cdrom              /mnt/cdrom              udf,iso9660 noauto,owner,kudzu,ro 0 0
    /dev/fd0                /mnt/floppy             auto    noauto,owner,kudzu 0 0

    fstab中存放了與分區有關的重要信息,其中每一行為一個分區記錄,每一行又可分為六個部份:
    1. 第一項是您想要mount的儲存裝置的實體位置,如/dev/sda6分區 (分區或卷標名)
    2. 第二項就是您想要將其加入至哪個目錄位置,如/home或/, (掛載點 )
    3. 第三項就是所謂的local filesystem,其包含了以下格式:如ext、ext2、msdos、iso9660、nfs、swap等,或如ext2  (文件系統)
    4. 第四項就是您mount時,所要設定的狀態,如ro(只讀)或defaults(包括了其它參數如rw、suid、exec、auto、nouser、async),可以參見「mount nfs」。 (讀寫狀態)
    5. 第五項是提供DUMP功能,在系統DUMP時是否需要BACKUP的標志位,其內定值是0。  (0為不備份,1為要備份,一般根分區要備份)               
    6. 第六項是設定是否要在開機時做check的動作,除了其必要的check為1之外,其它皆可視需要設定,內定值是0。 (0為不自檢,1或者2為要自檢,如果是根分區要設為1,其他分區只能是2)
    posted @ 2008-10-30 11:23 agapple 閱讀(280) | 評論 (0)編輯 收藏

    僅列出標題  下一頁
    主站蜘蛛池模板: 五月天网站亚洲小说| 99久久国产亚洲综合精品| 亚洲理论片中文字幕电影| 一道本不卡免费视频| 国产香蕉九九久久精品免费| 亚洲欭美日韩颜射在线二| 国产亚洲精品91| 日韩免费高清视频网站| 亚洲国产成人九九综合| 无码少妇精品一区二区免费动态| 亚洲精品成人区在线观看| 亚洲色大成网站www| 中文字幕人成无码免费视频| 亚洲成av人片不卡无码| 久久国产免费观看精品3| 亚洲高清国产AV拍精品青青草原| 国产精品免费观看视频| 亚洲精品tv久久久久| 中文字幕在线观看免费视频| 免费又黄又爽又猛大片午夜| www国产亚洲精品久久久 | 久久亚洲精品无码av| 免费无码精品黄AV电影| 最近免费字幕中文大全| 亚洲综合色自拍一区| a级在线免费观看| 国产成人综合久久精品亚洲| 亚洲第一页在线播放| 国产91精品一区二区麻豆亚洲 | 高清国语自产拍免费视频国产 | 亚洲精品国产成人片| 久久免费动漫品精老司机| 亚洲视频一区二区三区| 久久午夜免费视频| 色欲aⅴ亚洲情无码AV| 亚洲日韩精品射精日| 免费jlzzjlzz在线播放视频| CAOPORM国产精品视频免费| 亚洲精品国产suv一区88| 亚洲?v女人的天堂在线观看| 国产成人A在线观看视频免费|