shell day day up----文件安全与权限

本文深入探讨Linux文件权限的概念,包括文件类型的识别、权限表示、改变权限的方法、目录权限的特殊规则,以及suid/guid位的作用。同时,介绍了如何使用chown/chgrp命令改变所有权,以及umask在文件创建时的重要性。最后,详细讲解了符号链接的使用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

《本文整理自网络上的一本书籍》

一、文件信息介绍


总用量 169772 指的是该目录(nunu目录)中所有文件所占的空间

下面分析每一行的具体意义

第一位(d,r)指的是文件的类型。一共有七种类型:

d 目录

l 符号链接(指向另一个文件_现在理解为快捷方式)

s 套接字文件

b 块设备文件

c 字符设备文件

p 命令管道文件

- 普通文件,就是指不属于以上几种的文件类型

后面紧随有9个字母---每三位为一组(r表示读权限、w表示写权限、x表示执行权限)

rwx-xr-x中

rwx:文件属主权限--创建该文件的用户-前三位

r-x:同住用户的权限--与属主统一用户组的用户的权限-中间三位

r-x:其他用户的权限-后三位

在后面的数字 表示该文件硬链接数目

再后面的nunu 表示文件的属主

在后面的nunu 表示该文件的属主所在的缺省组

在后面数字4096 用字节表示的文件长度

再后面为文件的更新时间

再后面为文件名

二、改变权限问

2.1、符号模式

命令的一般格式:
chmod [who] operator [permission] filename
其中who
u 文件属主权限
g 同组用户权限
o 其他用户权限
a 所有用户

operator:

+ 增加权限

- 减少全乡

= 设定权限

permission

r 读权限

w 写权限

x 执行权限

s 文件属主和组set-ID

t 粘性为*(如有说明只有属主可以删除文件)

l 给文件加锁,使其他用户无法访问



2.2、绝对模式

chmod [mode] file
其中mode是一个八进制数
0400 文件属主可读
0200 文件属主可写
0100 文件属主可执行
0040 同组用户可读
0020 同组用户可写
0010 同组用户可执行
0004 其他用户可读
0002 其他用户可读
0001 其他用户可执行

如果要赋值就是对3中权限的全部赋值。需要哪些权限只要相加就好


另外如果希望一次性设置目录下所有文件权限可这样写:chmod 644*

如果想连同子目录下文件一起设置可这样写:chmod -R 664 /usr/local/*

三、目录权限

目录权限含义有所不同。读权限以为用户可以列出其中的内容、写权限以为可以创建-删除文件、执行表示用户可以搜索和访问该目录

另外目录权限会覆盖底下的文件目录

四、suid/guid位

suid如果被置位表示其他用户操作该脚本是拥有该属主的权限

guid则表示其他用户操作该脚本时拥有该属主所属组的权限

符号模式:chmod u+s <filename>

绝对模式:chmod 4777 <filename> ---第一位2为guid 4为suid

五、chown/chgrp

chown -R -h owner file

h表示改变呼号连接文件的属主时不影响该连接所指向的目标文件

找出自己的用户组可用id命令

六、umask

umask确定你创建文件的缺省模式。一般来说umask命令在/etc/profile文件中设置的,每个用户登录时都会引用这个文件。所以希望改变所有用户的umask,可以再该文件中加入响应的条目。如果希望永久的设置自己的umask,那么就把它放在自己HOME目录下的.profile或则.bash_profile文件中

umask可以是777减去你设置的umask值(umask值为000-777)。这里需要区别文件开始时候都是没有执行权限的,所以要扣除掉执行的权限。

七、符号链接

连接包括软链接和硬链接。下面介绍软链接

软链接实际上是一个指向文件的指针,相当与window下的快捷方式

ln [-s] source_path target_source

We are given a log file that contains a sequence of events related to an update process on a device. The log is from the perspective of an automated test system (autotest) that is monitoring the update process. The key events in the log: 1. The test system is trying to establish an SSH connection to the device at 192.168.231.225. Initially, the connection is down, so it tries to start a new connection. 2. At 04:38:48, there's a timeout error waiting for the main SSH connection to come up. 3. Then, at 04:39:06, we see that the device has switched slots (likely due to an update) and the test breaks out of a waiting loop. 4. The test then checks the status of the update engine by running `update_engine_client --status` via SSH. The output shows that the update is in the DOWNLOADING state with progress at about 13%. 5. The test then retrieves the update_engine log and we see the log entries from the device's update_engine daemon. The update_engine log shows: - The update_engine starts at 04:39:01. - It identifies that the device is booted from slot A (slot 0). - It's an unofficial build, so periodic update checks are blocked. - It begins an update for a DLC (Downloadable Content) called "timeofday-dlc". The download URL is provided, and the download completes successfully (HTTP 200) at 04:39:05, with 23064576 bytes downloaded. - After verifying the hash, the DLC is mirrored and set to Active. - Then, the update_engine starts another update for a different DLC: "ml-dlc-a97333ed-3157-49a3-b503-2d2d3f23c81d". The log shows the installation starting for this DLC. However, the test then fails because it cannot find the update_engine logs to verify the update. The last lines in the log are: ``` 06/05 04:39:09.952 DEBUG| test:0439| Test failed due to update_engine logs are missing. Cannot verify update.. Exception log follows the after_iteration_hooks. ``` This indicates that the test expected to find update_engine logs for the entire update process, but at the time it checked (04:39:09), the log for the second DLC update was not available (or the test looked in the wrong place). But note: the test did retrieve the update_engine log at 04:39:09.856 (the file `update_engine.20250604-213901`). However, that log only covers the first DLC (timeofday-dlc) and the beginning of the second DLC (ml-dlc). The second DLC update was still in progress when the test checked. The test then, at 04:39:09.920, runs `ls -t -1 /var/log/update_engine/` and gets only one log file: `update_engine.20250604-213901`. This is the same log that was previously retrieved. The test then fails because it expects to see logs for the entire update (which might include multiple log files or a more recent one) but only one is present. It's possible that the update_engine daemon rotates logs and the test expects a new log for the second update? However, the log we see spans from 04:39:01 to 04:39:07 (and beyond, but the test only retrieved up to 04:39:09.913 in the log). The test failure message says "update_engine logs are missing", meaning it couldn't find the logs it expected. Alternatively, the test might be looking for a log entry that confirms the entire update (including the second DLC) completed, but the log we have only shows the start of the second DLC update. Given the information, the problem appears to be that the test is failing because it cannot find the expected update_engine logs to verify the update. This could be because: - The test is not waiting long enough for the update to complete and the logs to be written. - The update_engine log rotation might have occurred and the test is not accounting for the latest log file. - The test expects a specific log entry that is not present in the retrieved log. However, from the provided log, we can see that the update_engine was in the middle of updating the second DLC when the test checked. The test then immediately tried to get the logs again and found only one log file, which it had already retrieved. The test code seems to be in a state where it breaks out of the waiting loop because it detected a slot switch (which happened for the first DLC) but then it tries to verify the entire update (which includes multiple DLCs) and fails because the second DLC update was still ongoing and the logs were not complete. In summary, the issue is that the test did not wait for the entire update (all DLCs) to complete before attempting to verify the logs. It only waited for the first DLC to complete and the slot switch, but then proceeded to check the logs while the second DLC update was still in progress. Recommendation: The test should wait until the update_engine status indicates that the update is fully completed (e.g., IDLE) and then verify the logs. 翻译成中文
06-06
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值