linux中的shadow文件以及所采用的加密算法

转自: http://www.wzzjla.com/Html/201209/500.html

 

在现在的linux和unix系统中,用户的密码都保存在shadow文件中,因为密码关系到系统的安全,所以只有root用户才有读shadow文件的权限。shadow中存放的内容是有着一定的格式的,看如下例子:

root:$1$v2wT9rQF$XSpGgoB93STC4EFSlgpjg1:14181:0:99999:7:::

冒号是分割符,分别代表着,每个字段分别代表着:

:用户名

:密码hash值

:密码修改距离1970年1月1日的时间

:密码将被允许修改之前的天数(0 表示“可在任何时间修改”)

:系统将强制用户修改为新密码之前的天数(1 表示“永远都不能修改”)

:密码过期之前,用户将被警告过期的天数(-1 表示“没有警告”)

:密码过期之后,系统自动禁用帐户的天数(-1 表示“永远不会禁用”)

:该帐户被禁用的天数(-1 表示“该帐户被启用”)

:保留供将来使用

在hash值那一栏,两个”$”符号之间的数字代表不同的加密算法,系统不同所使用的算法也不尽相同。第二个”$”符号之后的字符串就是salt值,加密的时候需要用到(好像是取每八个字符的每个字符的低7个bit位(取得的结果为01串)),然后得到8*7=56个bit位,然后用一定的规则反复加密(我不知道是什么规则),返回指向包含13个可打印的ASCII码字符([a-zA-Z0-9./])的指针,通常取前两位作为salt位,

数字和所使用的加密算法对应关系:

1: MD5 ,(22位)

2a: Blowfish, 只在有一部分linux分支中使用的加密方法

5: SHA-256  (43位)

6: SHA-512   (86位)

后面两种加密算法只在glibc2.7版本之后才支持。

第3个”$”后面的字符串就是加密后的密文了(应该是截取了加密密文中的某一段)

以下是crypt文档的部分内容:

The glibc2 version of  this  function  supports  additional  encryption
algorithms.

If  salt is a character string starting with the characters “$id$” fol‐
lowed by a string terminated by “$”:

$id$salt$encrypted

then instead of using the DES machine,  id  identifies  the  encryption
method  used  and  this  then  determines  how the rest of the password
string is interpreted.  The following values of id are supported:

ID  | Method
─────────────────────────────────────────────────────────
1   | MD5
2a  | Blowfish (not in mainline glibc; added in some
| Linux distributions)
5   | SHA-256 (since glibc 2.7)
6   | SHA-512 (since glibc 2.7)

So   $5$salt$encrypted   is   an   SHA-256   encoded    password    and
$6$salt$encrypted is an SHA-512 encoded one.

“salt” stands for the up to 16 characters following “$id$” in the salt.
The encrypted part of the password string is the actual computed  pass‐
word.  The size of this string is fixed:

MD5     | 22 characters
SHA-256 | 43 characters
SHA-512 | 86 characters

The  characters  in  “salt”  and  “encrypted”  are  drawn  from the set
[a–zA–Z0–9./].  In the MD5 and SHA implementations the  entire  key  is
significant (instead of only the first 8 bytes in DES).

PHP中关于max_execution_time的实现机制

PHP中的 max_execution_time 是通过setitimer来实现的:

文件: Zend/zend_execute_API.c

 

说明: 当程序执行到最大时间时,将会收到一个SIGPROF的信号,PHP处理了这个信号,至于哪些时间计算到最大执行时间中,且看setitimer的文档:

SYNOPSIS
#include <sys/time.h>

int getitimer(int which, struct itimerval *value);
int setitimer(int which, const struct itimerval *restrict value,
struct itimerval *restrict ovalue);

DESCRIPTION
The getitimer() function shall store the current value of the timer specified by which into the structure pointed to by value. The setitimer() function shall set the timer specified by which to the value specified in the structure pointed to by value, and if ovalue is not a null pointer, store the previous value of the timer in the structure pointed to by ovalue.

A timer value is defined by the itimerval structure, specified in <sys/time.h>. If it_value is non-zero, it shall indicate
the time to the next timer expiration. If it_interval is non-zero, it shall specify a value to be used in reloading
it_value when the timer expires. Setting it_value to 0 shall disable a timer, regardless of the value of it_interval. Setting it_interval to 0 shall disable a timer after its next expiration (assuming it_value is nonzero).

Implementations may place limitations on the granularity of timer values. For each interval timer, if the requested timer value requires a finer granularity than the implementation supports, the actual timer value shall be rounded up to the next supported value.

An XSI-conforming implementation provides each process with at least three interval timers, which are indicated by the which argument:

ITIMER_REAL
Decrements in real time. A SIGALRM signal is delivered when this timer expires.

ITIMER_VIRTUAL
Decrements in process virtual time. It runs only when the process is executing. A SIGVTALRM signal is delivered when it expires.

ITIMER_PROF
Decrements both in process virtual time and when the system is running on behalf of the process. It is designed to be used by interpreters in statistically profiling the execution of interpreted programs. Each time the ITIMER_PROF

timer expires, the SIGPROF signal is delivered.

The interaction between setitimer() and any of alarm(), sleep(), or usleep() is unspecified.

 

—————————–
疑惑: 既然PHP的执行时间限制是使用setitimer来实现的,那么为什么官方文档还有那么多莫名其妙的解释呢?

如:http://us1.php.net/manual/zh/function.set-time-limit.php

Note:

set_time_limit()函数和配置指令max_execution_time只影响脚本本身执行的时间。任何发生在诸如使用 system()的系统调用,流操作,数据库操作等的脚本执行的最大时间不包括其中,当该脚本已运行。在测量时间是实值的Windows中,情况就不是如此了。

关于XMLHttpRequest对302的处理

摘自: http://hi.baidu.com/erik168/item/41a5910c1eca0627a0312dd8

【未亲自测试,请斟酌参考】

javascript代码:

302local.php:
header(“Location:hello.php”);

302net.php:
header(“Location:http://www.baidu.com”);

测试浏览器:
IE7
Firefox3.5
Opera9.6
Safari4

结论:
1.在重定向到本域时,无论如何都无法获得302状态码,XMLHttpRequest对象会直接读取重定向资源的内容

Fx3.5 alert:
status:200;readyState:2
status:200;readyState:3
status:200;readyState:4

IE7 alert:
status:200;readyState:4

Safari4 alert:
status:200;readyState:2
status:200;readyState:3
status:200;readyState:4

Opera9.6 alert:
status:200;readyState:3
status:200;readyState:4

2.在重定向到其他域时:
Safari和Opera会哑掉
IE会问你“可能导致安全风险,是否继续”,是的话取得status是200,否的话取得status是0
Firefox会获得302的status

Fx3.5 alert:
status:302;readyState:2
status:302;readyState:4

IE7 alert:
status:200;readyState:4
or
status:0;readyState:4

以crond为例学习后台程序的经典写法

这里了解一下对于一个后台程序是如何处理标准输入、标准输出、标准错误的。

vixie-cron-4.1

 

Attaching Android platform source in Eclipse

问题

按照adroid.com 来配置的adroid开发环境,其它都很顺利,唯独无法查看adroid的源代码,现象如下:

 

解决办法

我的android-sdk的安装路径: D:\Android\android-sdk  我已经通过adt工具下载了android-16的源代码,默认放在目录: D:\Android\android-sdk\sources\android-16 中的, 现在把该目录移动(或复制) 到 D:\Android\android-sdk\platforms\android-16\sources 即可,需要重启eclipse

原因: adroid不允许加载项目外部的源代码,也因此,在windows上也不能使用“快捷方式”来把D:\Android\android-sdk\platforms\android-16\sources 快捷方式到 D:\Android\android-sdk\sources\android-16

 

不明白的是: 1. eclipse的android开发插件是官方开发的    2. android-sdk-manager也是官方开发的  3. 为什么就不能把源代码下载到能加载的目录呢?

 

参考资料:

http://blog.163.com/fan_jianglong@126/blog/static/561705362012574356790/

http://android.opensourceror.org/2010/01/18/android-source/

关于证书的一些概念

根证书


在密码学和计算机安全领域中,根证书是未被签名的公钥证书或自签名的证书。根证书是CA认证中心给自己颁发的证书,是信任链的起始点。安装根证书意味着对这个CA认证中心的信任

从技术上讲,证书其实包含三部分,用户的信息,用户的公钥,还有CA中心对该证书里面的信息的签名,要验证一份证书的真伪(即验证CA中心对该证书信息的签名是否有效),需要用CA 中心的公钥验证,而CA中心的公钥存在于对这份证书进行签名的证书内,故需要下载该证书,但使用该证书验证又需先验证该证书本身的真伪,故又要用签发该证书的证书来验证,这样一来就构成一条证书链的关系,这条证书链在哪里终结呢?答案就是根证书,根证书是一份特殊的证书,它的签发者是它本身,下载根证书就表明您对该根证书以下所签发的证书都表示信任,而技术上则是建立起一个验证证书信息的链条,证书的验证追溯至根证书即为结束。所以说用户在使用自己的数字证书之前必须先下载根证书。

自签名证书


自签名证书是其签发者(签名者)与主题(其公共密钥由该证书进行验证的实体)相同的证书

 

未签名证书与自签名证书


  1. 二者都无法校验其身份的真实性
  2. 自签名证书通过“用户确认”(信任该颁发结构,其实还是自己)可以完成其校验流程;未签名证书不知道颁发机构是谁,就算知道是谁,也因为没有签名而无法校验。

证书链


证书链由两个环节组成—信任锚(CA 证书)环节和已签名证书环节。自我签名的证书仅有一个环节的长度—信任锚环节就是已签名证书本身。

证书链可以有任意环节的长度,所以在三节的链中,信任锚证书CA 环节可以对中间证书签名;中间证书的所有者可以用自己的私钥对另一个证书签名。CertPath API 可以用来遍历证书链以验证有效性,也可以用来构造这些信任链。

Web 浏览器已预先配置了一组浏览器自动信任的根 CA 证书。来自其他证书授权机构的所有证书都必须附带证书链,以检验这些证书的有效性。证书链是由一系列 CA 证书发出的证书序列,最终以根 CA 证书结束。

证书最初生成时是一个自签名证书。自签名证书是其签发者(签名者)与主题(其公共密钥由该证书进行验证的实体)相同的证书。如果拥有者向 CA 发送证书签名请求 (CSR),然后输入响应,自签名证书将被证书链替换。链的底部是由 CA 发布的、用于验证主题的公共密钥的证书(回复)。链中的下一个证书是验证 CA 的公共密钥的证书。通常,这是一个自签名证书(即,来自 CA、用于验证其自身的公共密钥的证书)并且是链中的最后一个证书。

在其他情况下,CA 可能会返回一个证书链。在此情况下,链的底部证书是相同的(由 CA 签发的证书,用于验证密钥条目的公共密钥),但是链中的第二个证书是由其他 CA 签发的证书,用于验证您向其发送了 CSR 的 CA 的公共密钥。然后,链中的下一个证书是用于验证第二个 CA 的密钥的证书,依此类推,直至到达自签名的根证书。因此,链中的每个证书(第一个证书之后的证书)都需要验证链中前一个证书的签名者的公共密钥。

 

代码签名


http://baike.baidu.com.cn/view/480143.htm

神奇的“粘住位”

教材中关于“粘住位”的解释:

==========================================

UNIX环境高级编程

文件和目录

文件的粘住位 ( S _ I S V T X ),在U N I X的早期版本中,有一位被称为粘住位(sticky bit) 。如果一个可执行程序文件的这一位被设置了,那么在该程序第一次执行并结束时,该程序正文的一个文本被保存在交换区。(程序的正文部分是机器指令部分)这使得下次执行该程序时能较快地将其装入内存区。其原因是:在交换区,该文件是被连续存放的,而在一般的 U N I X文件系统中,文件的各数据块很可能是随机存放的。对于常用的应用程序,例如文本编辑程序和编译程序的各部分常常设置它们所在文件的粘住位。
自然,对交换区中可以同时存放的设置了粘住位的文件数有一定限制,以免过多占用交换区空间,但无论如何这是一个有用的技术。因为在系统再次自举前,文件的正文部分总是在交换区中,所以使用了名字“粘住” 。后来的U N I X版本称之为保存 -正文位(saved-text bit) ,因此也就有了常数 S _ I S V T X。现今较新的U N I X系统大多数都具有虚存系统以及快速文件系统,所以不再需要使用这种技术。S V R 4和4 . 3 + B S D中粘住位的主要针对目录。如果对一个目录设置了粘住位,则只有对该目录具有写许可权的用户并且满足下列条件之一,才能删除或更名该目录下的文件:
· 拥有此文件。
· 拥有此目录。
· 是超级用户。
目录/ t m p和/ v a r / s p o o l / u u c p p u b l i c是设置粘住位的候选者—这两个目录是任何用户都可在其中创建文件的目录。这两个目录对任一用户 (用户、组和其他)的许可权通常都是读、写和执行。但是用户不应能删除或更名属于其他人的文件,为此在这两个目录的文件方式中都设置了粘住位。

==========================================

对于目录 /test/ 来讲,如果读写权限为755,属主为test:test , 则 其它用户(如:test2)将无法在该目录下创建(或删除)文件或目录,如果该目录下存在一个读写权限为666的文件,则 test2 可以修改该文件的内容,不能删除该文件:如果要允许test2也能在该目录下创建文件,则test2也必将可以删除该目录下的任何文件(虽然可能无法读写文件)。

对于/tmp 这个特殊的目录来讲,即允许任何人创建和删除文件,又不允许删除不是自己的文件,按照上述的权限控制逻辑是做不到的,于是“粘住位”就有了用武之地了。这样就达到了允许创建、删除文件,但是无法删除别人的文件,每个人把文件属性设置后600就会很安全了,大家工作在同一个目录下,而且不能相互读写以及删除,多么神奇的想法啊。

 

给目录设置粘住位,达到/tmp 这样的效果; 给文件设置“粘住位”呢? 注意: linux (仅限linux)忽略文件的“粘住位”

设置“粘住位”

chmod 1777 the_dir