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 阅读(1300) | 评论 (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心跳检查功能,能自动的剔除无效的链接。 

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

 

最后:

Dbcp将是我们以后数据库驱动选择的趋势,最后我们如何选择如何自动重连,这个也得根据我们的应用场景而定。比如只读的web系统,后台业务系统,任务系统可能处理方式就不同。

只读Web系统:可采取请求探雷的策略,也就失败连接池个数的请求,失败了页面刷新一次就好。

后台业务系统:一般业务都涉及数据库的写操作,很多数据不可重入,一次处理失败后就只能靠手工干预处理。这时候得考虑是否需要使用sql心跳检查,比如testOnBorrow或者testWhileIdle.

posted @ 2010-10-23 01:01 agapple 阅读(952) | 评论 (0)编辑 收藏

2009年2月15日 #

     摘要:   阅读全文
posted @ 2009-02-15 21:47 agapple 阅读(6386) | 评论 (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 阅读(731) | 评论 (0)编辑 收藏

2008年11月7日 #

     摘要:   阅读全文
posted @ 2008-11-07 20:48 agapple 阅读(2589) | 评论 (0)编辑 收藏

2008年11月3日 #

     摘要:   阅读全文
posted @ 2008-11-03 20:13 agapple 阅读(417) | 评论 (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 阅读(461) | 评论 (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 阅读(308) | 评论 (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 阅读(766) | 评论 (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 阅读(271) | 评论 (0)编辑 收藏

仅列出标题  下一页