Hot answers tagged permissions
5
Whether you can create, rename and delete a file does not depend on the ownership and access rights of the file but of those of the parent directory.
If you have write access to the directory (in the normal case, it's more complicated with richacl) then you can do this. The exception are directories with the sticky bit (the "SUID"/"SGID" bit for "others", ...
4
Look at the error output: you should be seeing find: `…' Permission denied errors. The first thing you do is remove all access permissions from $topdir, which prevents recursing further into it. None of the chmod commands you expect are executed except for the very first one.
If you want to remove the permission to access all the directories in a tree, you ...
4
The permissions in the bit patterns you gave in your question are broken down as follows:
example #1
example #2
...
3
The '.' at the end of the ls permissions output says there are extended data of some kind. chattr(1) gives the list of attributes for ext? file systems, lsattr(1) lists the current ones. Also check tha ACL for the file (getfacl(1)). A security policy (like SELinux) could also forbid some operations on the file.
3
sed -i ... file
actually does something like:
sed ... file > some-temp-file &&
mv some-temp-file file
That last mv does a rename. That is sed -i doesn't edit the file in place, it replaces it with a modified copy of itself.
Here it's the rename that is blocked. It is not blocked because of permission issues (you'd get a permission denied ...
3
Yes, you can do that changing the umask. The umask determines which are the default permissions for a newly creted file.
You can add umask g+w at the end of your shell configuration file (~/.bashrc for example).
But actually, it´s not a recommendable practice. In the case you do want to ensure the integrity of a file and you forget to update the file ...
3
If you are modifying real-person group affiliations, they need to just log out and log back in.
If you are changing group permissions for a system-like account (e.g. mysql, httpd) you'd have to restart the relevant daemons, but it is sometimes hard to know all the processes that need the new GIDs which are only applied when the process is started. Rebooting ...
3
chmod 777 CFB1-5DDA fails because CFB1-5DDA is a mount point and the mounted file system is vfat. So you are trying to write meta data to a file system which the file system does not support (i.e. cannot store). Simple as that.
strace chmod 777 CFB1-5DDA shows you the kernel error.
In order to change the access rights you have to change the mount (-o ...
3
Q: Is my folder structure correct/ideal?
A: Folder structure seems fine.
Q: I know I've used recursive (-R) option, but should I be repeating the same for $vhost/www, $vhost/logs and $vhost/backups?
A: It would be redundant to run it on those directories
Q: Am I correct in thinking that the chmod above is probably redundant?
Yes technically it's ...
3
The directory has no x permission, so others (i.e., in this case any user) can use the directory to reach the files inside. The T means it is sticky (only the owner of a file can delete it). With both the x permission and the sticky bit, you would see a lowercase t; the uppercase T says “no access permission but sticky bit, which is an odd combination”.
...
2
Well,
That would be because the way your current permissions are set, no one can move that file. ( Other than root, because root doesn't follow the same rules. )
You would need to either change the owner of the file (chown), OR add the other user to the group 'root' and chmod it so the group can execute on the directory, OR allow everyone else to execute ...
2
Folder b and c are owned by user b and c.
A file created by a user will belong to that user.
You can use the user permission for b and c, and the group permissions for a.
If you set the SGID bit (g+s) on a folder, created files will get the group permission of that folder.
mkdir a
chown a:a a
chmod g+s a
mkdir b
chown b:a b
mkdir c
chown c:a c
...
2
Set ADD_EXTRA_GROUPS and EXTRA_GROUPS in /etc/adduser.conf. From the manpage:
ADD_EXTRA_GROUPS
Setting this to something other than 0 (the default) will cause
adduser to add newly created non-system users to the list of
groups defined by EXTRA_GROUPS (below).
EXTRA_GROUPS
This is the list of groups that ...
2
chmod -R o-w .
Will remove write permissions to others for every file in a safe way. It will however update the ctime of every file including the ones for which others already didn't have write access.
With GNU chmod, you can make it show which files needed updated with the -c option:
$ chmod -cR o-w .
mode of `./a' changed from 0777 (rwxrwxrwx) to 0775 ...
2
If this is going to accessible via the network, yes. In order for apache to access the public_html it's going to need some level of access to root's home directory (which could be catastrophic if they somehow found a way, via software vulnerability or unsafe configuration, to add something to root's .bash_profile or something).
Run as little as humanly ...
1
You should set DIR_MODE in /etc/adduser.conf and use the adduser command as recommended in the man page for useradd on your system:
adduser testuser
If you do not want to make changes to the original /etc/adduser.conf (or need different setups) you can make changes in a copy and use adduser --conf <yourconf>
1
Your approach is a performance nightmare: You create two processes for every file! One completely uselessly because find already has this information and can easily print it. This is a better solution:
find . -perm -o=rwx -printf "%m %p_\0" 2>/dev/null |
while read -r -d '' perms path; do
path="${path%_}"
echo "${perms} '${path}'" >&2
...
1
/007 will show your only files that have no permissions for owner and group, and all permissiosn (rwx) for other.
You might have more luck with /o=rwx. That will match only the other permissions for the file.
EDIT FOR CORRECTNESS:
Apparently, you'll need to use -perm -o=rwx, because the /o is an inclusive filter, and would match files where other has ...
1
They can have permissions to delete files, so long as they have write permissions on the directory the files are inside. Only the owner can change the permissions using normal Unix permissions.
NOTE: If you're a member of a group and the permissions on the file are rwx, the members of the group can edit the file and execute it, nothing more. The rest of ...
1
Your display manager (lightdm, openbox, etc.) is a child of init which is owned by root. Init isn't set-uid because it's a very special process and is just started with uid of 0. The command ps -eaH gives a structured view of parentage, the relevant bits are:
r 1 ? 00:00:00 init
r 1521 ? 00:00:00 lightdm
r 1531 tty7 00:00:12 Xorg
...
1
Given those permissions, only the owner of the directory or the super user can create subdirectories.
The only way that you could avoid use extra privileges to create the folder is change the ownership to yourself (with sudo), create the subdirectory and finally return the ownership to the owner, but doesn't look like a good solution to me.
1
I couldn't figure out which partition/mount is actually backing the directory/files that are giving you permissions problems.
If it's an NTFS or possibly one of the fuse ones then the permissions displayed on your client can be misleading. They aren't necessarily the actual permissions. The true permissions for these are governed by the actual account ...
Only top voted, non community-wiki answers of a minimum length are eligible
