前言
1.linux的组权限允许多个用户对系统中的对象（比如文件，目录，设备等）共享一组的权限。
2. 新建用户的话adduser命令会直接帮我们设置很多信息，useradd结合命令参数可以更好的帮助我们对用户进行设置，比如设置用户组，登录shell。
3. 有时我们希望服务器上同一个组可以相互拷贝文件，可以执行，但是不能写入，也就是，同一个组的可以相互借鉴参考，但你不能乱修改我的。而对于外人，可以不对其开放，或者只能读或执行，这样管理员更好的规范管理。新建组名和新建账户
以管理员账户登入 1 新建组，group是你新建的组名。 sudo groupadd group 2. 新建用户，并且建立在我们刚建立的组下，yourname是你的用户名字。 sudo useradd -g group -m -s /bin/bash yourname // useradd命令不会创建HOME目录， -m 可以使其创建HOME目录， -s 指定默认的登录shell， -g指定用户登录组的组名。 3.修改用户密码，不修改登不进去（也可以用 添加 -p xxx ，添加密码，但是会进行加密，导致密码并不是我们想设置的，不推荐，可通过修改密码，进行设置） sudo passwd yourname改变文件归属，改变文件所属用户组
1 更改文件的用户归属 //user为用户名，file_name为文件名字，若遍历文件夹，更改整个文件夹的归属，使用-R，dir_name为文件夹的名字。 sudo chown user file_name sudo chown user -R dir_name 2 改变文件所属用户组 // group为改变后的用户组，dir_name为需要改变组的文件夹名。 sudo chgrp group -R dir_name更改权限
// 关于权限问题可自行查阅相关知识，并根据自身需求设置，这里仅举个例子。 // 7代表文件属主的权限，有读取写入执行权限。5代表属组成员的权限，有读取和执行的权限。4代表其他账户的权限，仅有读的权限。dir_name为文件夹名字。 sudo chmod 754 -R dir_name
##用户帐号 /etc/passwd文件结构
root:x:0:0:root:/root:/bin/bash
每一行使用“：”分隔开，共有七段，分别是 1.帐号名称
2.密码
3.UID Linux对于UID有几个限制：
0（系统管理员）
1~499（系统帐号）
500~65535（可登录帐号） 4.GID
5.用户信息说明列
6.主文件
7.shell
##/etc/shadown文件结构
bin:*:14126:0:99999:7:::
1.帐号名称
2.密码
3.最近更动密码的日期
4.密码不可被更改的天数
5.密码需要重新更改的天数
6.密码需要更改期限前的警告天数
7.密码过期后的帐号宽限时间
8.帐号失效的天数
9.保留
##有效与初始用户组：groups,newgrp root:x:0:root
1.用户组名称
2.密码
3.GID
4.此用户组支持的账户名称
--用户管理讲解
在Linux中，每个用户都有一个账号，并且对于不同的系统资源拥有不同的使用权限
系统账号可以分为两种类型：
（1）用户账号（每个用户都拥有一个uid,gid）
1.管理员root用户和普通账户
（2）组账号
1.通过使用组账号，可以设置一组用户对文件具有相同的权限
2.管理员以组为单位分配对资源的访问权限，例如读取，写人或执行的权限
从而可以节省日常的维护时间。
2.可以通过组设置批量创建用户账号，提高效率。
Linux有6个虚拟终端,控制键是ctrl+alt+f1~f6 返回图形界面则是alt+f7
转载于:https://blog.51cto.com/1464490021/1845622
最近碰到一个配置文件的问题，简单的说，就是：自己开发的一个程序，修改配置文件之后，没有生效。
这个问题，对于程序的开发和维护人员来说比较常见，原因很多，今天要说的，是UAC的原因。
本文开头所说的情况，具体是这样的：我们项目组开发的程序，原来都是运行在Windows 2003上的，最近打算迁移到Windows 2008，某天，我用非Administrator用户（仍属于Administrators组）登录之后，用记事本修改了exe文件的配置文件，双击运行之后，更改的配置没有生效；但是当我在exe上点右键“以管理员身份运行”，则更改的配置生效。
如此诡异的现象，当然不能放过。查阅资料后才明白是UAC的原因。
解决上述问题的简单方法是“以管理员身份运行”，操作起来稍微复杂一点；或者禁用UAC，不过要牺牲系统安全性。
更有效的方法比较复杂，需要了解UAC的方方面面，这里列出一点资料，供参考：
转载于:https://www.cnblogs.com/ols/archive/2010/11/19/1881856.html
