linux 类型转换(linux安装软件包的命令)

如何将phpinfo字符串类型转换

php中iconv、mb_convert_encoding函数字符编码转换详解如下：

iconv函数库能够完成各种字符集间的转换，是php编程中不可缺少的基础函数库。

用法如下：

$string="亲爱的朋友欢迎访问博客，希望给您带来一点点的帮助！";

iconv("utf8","gbk",$string)//将字符串string编码由utf8转变成gbk；

扩展如下：

echo[MathProcessingError]str=′好,欢迎访问博客，该博客记录一个程序员的成长过程!′;echo′<br/>′;echoiconv(′GB2312′,′UTF−8′,str);//将字符串的编码从GB2312转到UTF-8

echo'<br/>';

echoiconv_substr([MathProcessingError]str,1,1,′UTF−8′);//按字符个数截取而非字节printr(iconvgetencoding());//得到当前页面编码信息echoiconvstrlen(str,'UTF-8');//得到设定编码的字符串长度

//也有这样用的

[MathProcessingError]content=iconv("UTF−8","gbk//TRANSLIT",content);

备注：

1、iconv不是php的默认函数，也是默认安装的模块。需要安装才能用的。

如果是windows2000+php，你可以修改php.ini文件，将extension=php_iconv.dll前的";"去掉，同时你要copy你的原php安装文件下的iconv.dll到你的winnt/system32下（如果你的dll指向的是这个目录，我本地的没有操作这一步）

在linux环境下，用静态安装的方式，在configure时加多一项--with-iconv就可以了，phpinfo看得到iconv的项。(Linux7.3+Apache4.06+php4.3.2)；

到此php中的iconv介绍完毕

2、用iconv函数把抓取来过的utf-8编码的页面转成gb2312，发现只有用iconv函数把抓取过来的数据一转码数据就会无缘无故的少一些。原因是这样的：

string iconv( string in_charset, string out_charset, string str)

注意：第二个参数，除了可以指定要转化到的编码以外，还可以增加两个后缀：//TRANSLIT和//IGNORE，其中//TRANSLIT会自动将不能直接转化的字符变成一个或多个近似的字符，//IGNORE会忽略掉不能转化的字符，而默认效果是从第一个非法字符截断。被截断了，当然就会少了；

可以这样修改iconv("UTF-8","GB2312//IGNORE",$string)会忽略掉不能转化的字符；

附加：

PHP中的mb_convert_encoding与iconv函数介绍

mb_convert_encoding这个函数是用来转换编码的，和iconv函数差不多。

英文一般不会存在编码问题，只有中文数据才会有这个问题。比如用Zend Studio或Editplus写程序时，用的是gbk编码，如果数据需要入数据库，而数据库的编码为utf8时，这时就要把数据进行编码转换，不然进到数据库就会变成乱码。

做一个GBK To UTF-8

<?php

header("content-Type:text/html;charset=Utf-8");//设置字符的编码是utp-8

echomb_convert_encoding("你系我的友仔","UTF-8","GBK");

?>

再做GB2312 To Big5

<?php

header("content-Type:text/html;charset=big5");

echomb_convert_encoding("朋友","big5","GB2312");

?>

不过要使用上面的函数需要安装但是需要先enable mbstring扩展库，道理还是一样的，修改php.ini。

PHP中的另外一个函数iconv也是用来转换字符串编码的，与上函数功能相似。

下面还有一些详细的例子：

iconv—Convertstringtorequestedcharacterencoding

(PHP4>=4.0.5,PHP5)

mb_convert_encoding—Convertcharacterencoding

(PHP4>=4.0.6,PHP5)

用法：

stringmb_convert_encoding(stringstr,stringto_encoding[,mixedfrom_encoding]

需要先enable mbstring扩展库，在 php.ini里将; extension=php_mbstring.dll前面的;

去掉mb_convert_encoding可以指定多种输入编码，它会根据内容自动识别,但是执行效率比iconv差太多；

那为何还要讲解这个 mb_convert_encoding()函数呢？答案如下：

发现iconv在转换字符”—”到gb2312时会出错，如果没有ignore参数，所有该字符后面的字符串都无法被保存。不管怎么样，这个”—”都无法转换成功，无法输出。

另外mb_convert_encoding没有这个bug.

一般情况下用 iconv，只有当遇到无法确定原编码是何种编码，或者iconv转化后无法正常显示时才用mb_convert_encoding函数.

Linux C - C基础篇(一)

1)最高位是符号位，0表示正数，1表示负数。

2)如果是正数，正常表示(即原码)，如果是负数，先求反码，再求补码（补码为反码加1）即为他的二进制表示。例如char型的1，用二进制表示为00000001；char型的-1用二进制表示为11111111。

常量，就是在程序运行过程中值无法被改变；变量，就是在程序运行过程中内部存储的值随时可以被改变。变量是“可读、可写”，而常量，是“只读”的。

整形常量：12、浮点型常量：12.35、实数型常量：1.3e-5、字符型常量：'a'、字符串型常量："abc"、标识符常量：#define LEN 10。

变量一般存放在内存中：栈区，静态数据区，全局变量区，堆区。函数中定义的变量，如果不加特殊修饰，都是保存在栈区，函数调用结束，栈空间被自动释放。

定义变量：

<存储类型><数据类型><变量名>

static/auto/... int/char a

例如：static int a；char c；

存储类型：

自动类型转换

将一种类型的数据赋值给另外一种类型的变量时就会发生自动类型转换，例如：float a= 10；10是int类型的数据，需要先转换成float类型然后再赋值给变量a。

在不同类型的混合运算中，编译器也会自动地转换数据类型，将参与运算的所有数据先转换为同一种类型，然后再进行计算。转换的规则如下：

强制类型转换

自动类型转换是编译器根据代码自己判断的，有时候我们需要手动的进行数据类型转换，称之为强制类型转换，例如：

(int)(a+b);//将a+ b求得结果的数据类型强制转换为int型。

运算符的优先级

特殊运算符>单目运算符>双目运算符>三目运算>赋值运算>逗号运算

SELinux权限

在了解SELinux之前，我们先来了解一下Linux的两种访问控制策略：DAC和MAC

DAC，自主访问控制（Discretionary Access control）。系统只提供基本的验证,完整的访问控制由开发者自己控制。

 DAC将资源访问者分成三类：Owner、Group、Other。

 将访问权限也分成三类：read、write、execute

资源针对资源访问者设置不同的访问权限。访问者通常是各个用户的进程，有自己的uid/gid，通过uid/gid和文件权限匹配,来确定是否可以访问。DAC机制下，每一个用户进程默认都拥有该用户的所有权限。

DAC有两个严重问题：

 问题一：

 因为Root用户是拥有所有权限的，所以DAC对Root用户的限制是无效的。并且在Linux Kernel 2.1以后，Linux将Root权限根据不同的应用场景划分成许多的Root Capabilities,普通用户也可以被设置某个Root Capability。普通用户如果被设置了CAP_DAC_OVERRIDE，也可以绕过 DAC限制。

 问题二：

 用户进程拥有该用户的所有权限，可以修改/删除该用户的所有文件资源,难以防止恶意软件。

可见，DAC有明显的缺陷，一旦被入侵，取得Root权限的用户进程就可以无法无天，胡作非为，早期android版本就深受其害。

MAC，强制性访问控制（Mandatory Access control）。系统针对每一项访问都进行严格的限制,具体的限制策略由开发者给出。

Linux MAC针对DAC的不足,要求系统对每一项访问,每访问一个文件资源都需要根据已经定义好了的策略进行针对性的验证。系统可以针对特定的进程与特定的文件资源来进行权限的控制。即使是root用户，它所属的不同的进程，并不一定能取得root权限，而得要看事先为该进程定义的访问限制策略。如果不能通过MAC验证，一样无法执行相关的操作。

与DAC相比，MAC访问控制的“主体”变成了“进程”而不是用户。这样可以限制了Root权限的滥用，另外要求对每一项权限进行了更加完整的细化,可以限制用户对资源的访问行为。

SELinux就是目前最好的MAC机制，也是目前的行业标准。

SELinux，安全增强Linux（Security-Enhanced Linux），是由美国国家安全局(NSA)发起,多个非营利组织和高校参与开发的强制性安全审查机制（Mandatory Access control，简称MAC）。SELinux最早于2000年12月采用GPL许可发布。目前，Linux Kernel 2.6及以上的版本都已经集成了SELinux。

SELinux分成三种模式：

Android 5.x及以上强制开启，因此，disabled(关闭)模式并没有什么用了。通常在调试时，我们会启用Permissve(宽容模式),以便尽可能的发现多的问题,然后一次修正。在量产时启用Enfocing mode(强制模式)来保护系统。

查看SELinux模式：adb shell getenforce

设置SELinux模式：adb shell setenforce 1//0是Permissve，1是Enfocing

SELinux的访问控制示意图：

通常我们开发的过程中，就是配置Subject、Object、Security Policy。

SELinux给Linux的所有对象都分配一个安全上下文(Security Context)，描述成一个标准的字符串。

安全上下文的标准格式： user:role:type[:range]

Security Label用来绑定被访问资源和安全上下文，描述它们的对应关系。标准格式为：resource security_context。即：res user:role:type[:range]。这里也可以使用通配符，例如 net.就可以绑定所有以net.开头的属性，除此之外，还有类似正则表达式的*、？等等通配符。Security Label都定义在type_contexts当中，例如file的定义在file_contexts中，service定义在service_contexts中，property定义在property_contexts中。

举例：

file_contexts:

service_contexts:

查看进程安全上下文： ps-AZ。例如，查看Settings进程的安全上下文，ps-AZ| grep settings：

  u:r:system_app:s0 system 1381 585 4234504 201072 0 0 S com.android.settings

查看文件安全上下文： ls-Z。例如，查看文件build.prop的安全上下文：

  u:object_r:system_file:s0 build.prop

Type Enforcement(TE)是根据Security Context中的 type进行权限审查,审查 subject type对 object type的某个class类型中某种permission是否具有访问权限，是目前使用最为广泛的MAC审查机制,简单易用。

TE控制语句格式: rule_name source_type target_type: class perm_set

Type Enforcement规则说明：

举个例子，logd.te、tombstoned.te中定义的TE规则：

  allow logd runtime_event_log_tags_file:file rw_file_perms;

  dontaudit domain runtime_event_log_tags_file:file{ open read};

  auditallow tombstoned anr_data_file:file{ append write};

  neverallow logd{ app_data_file system_data_file}:dir_file_class_set write;

SELinux中每一个进程或者文件都对应一个type,而每一个type都对应有一个或几个attribute。所有常见的attribute定义在以下文件中：

  system/sepolicy/public/attributes

  system/sepolicy/prebuilts/api/[build version]/public/attributes

  system/sepolicy/prebuilts/api/[build version]/private/attributes

其中的[build version]即为android版本号，例如android O为28.0。常见的attribute定义：

Type对应一个或者几个attribute，Type的定义格式：

  type type_name, attribute1, attribute2；

Type的定义通常分散在各个te文件中。例如，常用普通文件的type定义在file.te中：

SEAndroid对于不同的资源类型，定义了不同的Class。比如普通的file、socket等等，比如SELinux使用的security,比如针对每个process参数的process等定义相关的class。这些class，每一个class都有相对应的permissions。比如file就有 read, write, create, getattr, setattr, lock, ioctl等等.比如process就有fork, sigchld, sigkill, ptrace, getpgid, setpgid等等。这些相关的class,以及他们具有那些Permissions都定义在以下文件中：

  system/sepolicy/private/access_vectors

  system/sepolicy/reqd_mask/access_vectors

  system/sepolicy/prebuilts/api/版本号/private/access_vectors

例如：

定义完之后，在以下对应的security_classes文件中声明定义的classes。

  system/sepolicy/private/security_classes

  system/sepolicy/reqd_mask/security_classes

  system/sepolicy/prebuilts/api/版本号/private/security_classes

例如：

注意，Classes和Permissions的定义与Kernel中相关API是强相关的，普通用户严禁修改。

在SELinux中,我们通常称一个进程是一个domain,一个进程fork另外一个进程并执行(exec)一个执行档时,我们往往会涉及到domain的切换.比如init进程, SELinux给予了它很大的权限,而它拉起的服务,我们要限制这个服务的权限，于是就涉及到从一个domain切换到另外一个domain,不然默认就使用init进程的domain.

在SELinux里面有专门的一条语法: type_transition statement.

在准备切换前我们先要确保有相关的权限操作：

如下面的demo, init拉起apache并且切换到 apache的domain.

(1).首先，你得让init_t域中的进程能够执行type为apache_exec_t的文件

  allow init_t apache_exec_t: file{read getattr execute};

(2).然后，你还得告诉SELinux，允许init_t做DT切换以进入apache_t域

  allow init_t apache_t: process transition;

(3).然后，你还得告诉SELinux，切换入口（对应为entrypoint权限）为执行apache_exec_t类型的文件

  allow apache_t apache_exec_t: file entrypoint;

(4).最后，Domain Transition

  type_transition init_t apache_exec_t: process apache_t;

可以看到，整个domain切换过程写起来非常麻烦。因此，Google为了使用方便,在system/sepolicy/public/te_macros文件中定义了宏：

我们可以使用这些宏来完成domain切换。

举例：

kernel启动init进程切换domain:

  domain_auto_trans(kernel, init_exec, init)

init启动netd、vold、zygote、installd切换domain:

  init_daemon_domain(netd)

  init_daemon_domain(vold)

  init_daemon_domain(zygote)

  init_daemon_domain(installd)

一个进程创建在一个目录下创建文件时,默认是沿用父目录的Security Context,如果要设置成特定的Label,就必须进行Object Transitions.

同样是使用：type_transition statement.

对应的必须有两个前提条件:

下面是一个demo, ext_gateway_t这个domain在类型为in_queue_t的目录下，创建类型为 in_file_t的文件.

(1).首先，你得让ext_gateway_t对in_queue_t目录具备访问权限

  allow ext_gateway_t in_queue_t: dir{ write search add_name};

(2).然后，你还得告诉SELinux，允许ext_gateway_t访问in_file_t的文件

  allow ext_gateway_t in_file_t: file{ write create getattr};

(3).最后，Object Transition

  type_transition ext_gateway_t in_queue_t: file in_file_t;

同样的，为了方便使用，Google也在system/sepolicy/public/te_macros文件中定义了宏:

使用举例：

  file_type_auto_trans(factory, system_data_file, factory_data_file)

android O以前sepolicy集中放在boot image。前面提到SELinux在Android的主要变更历史时，有提到android O开始，Google将system image和 vendor image分离。因此，sepolicy也相应的被分离存放到system image以及 vendor image。与system相关的sepolicy就存放system image,与SoC vendor相关的sepolicy就存放在vendor image。

对于原生AOSP，Google设定了不同的存放目录,以便进行分离,以Google默认的sepolicy为例，sepolicy主目录为/system/sepolicy，我们主要关注三个子目录：

对于不同的平台，不同平台厂商也设定了不同的存放目录，以MTK平台为例：

首先，根据不同的platform共用sepolicy、platform独有、project独有，分为：

对应的，不同版本会导入不同目录下的sepolicy配置

以mt6763平台为例，导入时：

[common]路径为：/device/mediatek/sepolicy

[platfrom]路径为：/device/mediatek/mt6763/sepolicy/

具体的定义在BoardConfig.mk文件中:

然后，basic、bsp、full又可以主要细分为：

Google在system/sepolicy中定义了相关的neverallow规则,对SELinux Policy的更新进行了限制,以防止开发者过度开放权限，从而引发安全问题。并且还会通过CTS测试检测开发者是否有违法相关的规则。

因此，我们需要注意以下几点：

出现SELinux Policy Exception时常见的两种解决方案：

(1).修改对应节点的SELinux Security Label,为特定的Subject，如system_app、platform_app、priv_app，例如Settings，SystemUI等内置APP开启权限,但严禁为untrsted app开启权限。

(2).通过system server service或者 init启动的service读写操作,然后app通过binder/socket等方式连接访问.此类安全可靠,并且可以在service中做相关的安全审查,推荐这种方法.

情景:定义由 init进程启动的service, factory,其对应的执行档是/vendor/bin/factory。

(1).在device/mediatek/mt6763/sepolicy/basic/non_plat目录下创建一个factory.te,然后将te文件加入编译，如放到这种指定目录下不需要额外配置，sytem/sepolicy/Android.mk中定义的build_policy函数会遍历指定目录导入te文件。

(2).在factory.te中定义factory类型，init启动service时类型转换,

  type factory, domain;

  type factory_exec, exec_type, file_type, vendor_file_type;

  init_daemon_domain(factory)

(3).在file_contexts中绑定执行档

  /(system/vendor|vendor)/bin/factory u:object_r:factory_exec:s0

(4).根据factory需要访问的文件以及设备,定义其它的权限在factory.te中.

  #Purpose: For key and touch event

  allow factory input_device:chr_file r_file_perms;

  allow factory input_device:dir rw_dir_perms;

情景:添加一个自定义的system property： persist.demo，并为platform_app设置读写权限

(1).在property.te中定义system property类型

  type demo_prop, property_type

(2).在property_contexts中绑定system property的安全上下文。

  persist.demo u:object_r:demo_prop:s0

(3).在platform_app.te中新增写权限，可以使用set_prop宏。

  set_prop(platform_app, demo_prop)

(4).在platform_app.te中新增读权限，可以get_prop宏。

  get_prop(platform_app, demo_prop)

情景:有一个设备节点/dev/demo，有一个platform_app进程需要读写这个设备节点。

(1).在device.te中定义device类型

  type demo_device dev_type;

(2).在 file_contexts中绑定demo_device

  /dev/demo u:object_r:demo_device:s0

(3).在platform_app.te中，允许platform_app使用demo device的权限

  allow platform_app demo_device:chr_file rw_file_perms;

情景:有一个扩展的系统服务demo_service供APP调用。

(1).在service.te中定义service类型

  type demo_service, app_api_service, system_server_service, service_manager_type;

(2).在service_contexts中绑定service

  demo u:object_r:demo_service:s0

(3).在frameworks/base/core/java/android/content/Context.java中定义服务常量

  public static final String DEMO_SERVICE="demo";

(4).在frameworks/base/core/java/android/app/SystemServiceRegistry.java中，参照其它系统服务注册demo_service

(5).在frameworks/base/services/java/com/android/server/SystemServer.java中，启动DemoService，添加到service_manager进行管理。

(6).最后一步，参考其它系统服务，实现DemoManager、DemoService，并定义如IDemoService等等的AIDL接口。

情景:一个native service通过init创建一个socket并绑定在/dev/socket/demo,并且允许某些process访问.

(1).在file.te中定义socket的类型

  type demo_socket, file_type;

(2).在file_contexts中绑定socket的类型

  /dev/socket/demo_socket u:object_r:demo_socket:s0

(3).允许所有的process访问，使用宏unix_socket_connect(clientdomain, socket, serverdomain)

  unix_socket_connect(appdomain, demo, demo)

(1).在device/mediatek/mt6763/sepolicy/basic/non_plat目录下创建一个demo.te。

(2).在demo.te中定义demo类型，init启动service时类型转换。并可以根据demo需要访问的文件以及设备,定义其它的权限在demo.te中。

  type demo, domain;

  type demo_exec, exec_type, file_type;

  init_daemon_domain(demo)

(3).绑定执行档 file_context类型

  /vendor/bin/demo u:object_r:demo_exec:s0

(4).创建demo的入口执行档demo_exec、并配置相应的权限。

(1).将SELinux调整到Permissive模式复测

使用eng/userdebug版本，adb shell setenforce 0将SELinux模式调整到Permissive模式，然后复测。如果还能复现问题，则与SELinux无关；如果原本很容易复现,而Permissive mode不能再复现,那么就可能与SELinux相关。

(2).查看LOG中是否有标准的SELinux Policy Exception.

在Kernel LOG/ Main Log中查询关键字"avc: denied"看看是否有与目标进程相关的SELinux Policy Exception,并进一步确认这个异常是否与当时的逻辑相关。

一般情况我们在符合Google sepolicy策略及neverallow策略的前提下，根据LOG中的内容，需要什么权限就加什么权限。例如LOG：

2020-03-27 14:11:02.596 1228-1228/com.android.systemui W/FaceIdThread: type=1400 audit(0.0:481): avc: denied{ read} for name="als_ps" dev="tmpfs" ino=10279 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:als_ps_device:s0 tclass=chr_file permissive=0

LOG说明如下：

一般我们需要重点关注的是四个：permission、source type、target type、target class

根据这四个就可以配置出的所需要的selinux权限：

   allow [source type] [target type]: [target class] [permission]

例1：

03-27 03:45:22.632 2958 2958 W Camera: type=1400 audit(0.0:314): avc: denied{ read} for name="u:object_r:graphics_debug_prop:s0" dev="tmpfs" ino=2649 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:graphics_debug_prop:s0 tclass=file permissive=0

解决方案：

按正常的套公式，应该是这样修改platform_app.te，增加：

  allow platform_app graphics_debug_prop:file r_file_perms;

这里我们利用system/sepolicy/te_macros中定义的宏get_prop：

更多相关的宏定义请参考：system/sepolicy/public/te_macros。

所以最终简化后，修改platform_app.te，增加：

  get_prop(platform_app, graphics_debug_prop)

例2：

03-27 14:11:02.596 1228-1228/com.android.systemui W/BackThread: type=1400 audit(0.0:481): avc: denied{ read} for name="als_ps" dev="tmpfs" ino=10279 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:als_ps_device:s0 tclass=chr_file permissive=0

解决方案：

修改platform_app.te增加：

  allow platform_app als_ps_device:chr_file r_file_perms;

(1).不符合neverallow规则或者修改了neverallow规则

编译报错：

  neverallow check failed at xxx

CTS测试项failed：

  android.cts.security.SELinuxNeverallowRulesTest#testNeverallowRulesXXX

这类问题在android O vendor和system分离之后，尤其容易出现。基本上这类问题都是因为修改或者增加的te配置不符合neverallow规则，导致编译报错。而为了解决编译报错，又修改了neverallow规则，最终在跑CTS时，没法通过相关的测试项。

解决思路：

(2). init进程fork新进程没有做domain切换

CTS测试项failed：

  android.security.cts.SELinuxDomainTest# testInitDomain

解决思路：

fork进程时，参考3.4节中做domain切换。

本文主要参考了MTK-Online的Quick-start中《SELinux问题快速分析》的内容，感谢原作者们的辛勤付出。另外，结合源码和自身开发实践，增加了一些自身理解和实践内容。