Tag Info

Hot answers tagged

8

If you don't want to be challenged every time for your password then I'd recommend setting it to NOPASSWD in your /etc/sudoers file rather than hardcode your password in your logins. At least this way your primary login's password will remain intact and not be completely exposed in your .bashrc. To make this change run the command sudo visudo, and change ...


7

Install auditd and run: sudo auditctl -a exit,always -F arch=b64 -S fchmod -S chmod -S fchmodat \ -F path=/dev/null -k dev-null-chmod sudo auditctl -a exit,always -F arch=b32 -S fchmod -S chmod -S fchmodat \ -F path=/dev/null -k dev-null-chmod You'd find the culprit in the output of: sudo ausearch -ik dev-null-chmod You'll see the command name, pid ...


5

mv does not make a copy of the file and remove the original, unless you're moving the file between different filesystems. mv moves the file. In order to move a file, you need to have permission to detach it from the directory where it was before, and to attach it to the directory where you're putting it. In other words, you need write (and execute) ...


5

/tmp can be considered as a typical directory in most cases. You can recreate it, give it to root (chown root:root /tmp) and set 1777 permissions on it so that everyone can use it (chmod 1777 /tmp). This operation will be even more important if your /tmp is on a separate partition (which makes it a mount point). By the way, since many programs rely on ...


4

Gilles is correct; this is due to the changes in xorg-server 1.16 which were announced on the Arch News. To work around the permissions issue, you can use a Xorg.wrap config file to pass root rights, using: needs_root_rights = yes See man Xorg.wrap for the details. You could also try using xf86-video-modesetting instead of xf86-video-fbdev until the ...


4

A number of possibilities: the trailing dot in the file permissions line -rwSr-s---. indicate extended permissions, either SE Linux (confirm with ls -lZ) or ACL style permissions (confirm with getfacl ) which may block root overrides. the file has been made immutable with chattr ; confirm the file system attributes with lsattr The file is on a NFS ...


4

You've recursively changed permission on every file under root (/) and also filename. This is because you've a space between the two. You a few options: Fix the permissions. This will involve trying to figure out the correct permission for every file under / - a very time consuming task. One possible way to do this would be to install another copy of ...


3

When user tries to access a file or directory, the kernel allows to opens the file or directory with the mode parameter set to what permissions is assigned for that particular user. So if the user has only read permission the file opened by an application will be given only to read the contents of the file by the kernel.


3

I guess its pretty clear from the Man pages. And by the way what is your question? What part of the man page is not clear to you? With the execute bit set you have the permission to cd into the directory Also for long listing ls -l i.e. to view the meta data of the files inside the directory (Provided that read permission is there for the directory.


3

This is required by the POSIX standard for mkdir: For the -p option: Create any missing intermediate pathname components. followed by: and then calling the chmod() function with the following arguments: The same path argument as in the mkdir() call The value (S_IWUSR|S_IXUSR|~filemask)&0777 as the mode argument, where filemask is ...


3

This happens because you're only running the echo command as root. The output redirect is handled by your (non-root) shell. To avoid this, don't use the shell's redirect and use an actual command to handle the writing: tee. What you want to do can be done as so: echo "xyz" | sudo tee test > /dev/null (if you don't redirect the output, tee will output xyz ...


3

I'm not sure what best practice dictates as far as setting the "group" and "others" file permissions. A normal approach would be 755, so group and other have read-execute permission. Pretty much everything in (e.g.) /usr/bin is set that way. If I share my_file.sh and someone downloads it to their system, does the UID get changed to match their own? ...


2

rsync only preserves the owner if you ask it to with -o — otherwise files will be owned by the user running the rsync command, just like when any other files are created. -a includes -o, however, so lots of common rsync command lines include it. man rsync includes a passage on this explicitly: For example: if you want to use -a (--archive) but don’t want -o ...


2

You can have run.sh with "read by all" privilegs, but if e.g. /var/www/ is with privilegs "read only by root" you will get "permission denied" error message. check permissions of all directories in the path /var/ /var/www/ /var/www/etherpad-lite/ /var/www/etherpad-lite/bin/


2

SetUID bit on executable allows to run executable at file owner (not superuser). To be able to run executable as root, execute: sudo chown 0:0 ./setuid-test


2

You actually can't set permissions for many entries in procfs (in Linux at least) at all - they are handled by the kernel itself.


1

Use normal Linux/Unix permissions on your dude/photos to make sure that popolo can't access them. Assuming that popolo isn't the owner of those files and directories and isn't in the group, then a simple chmod -R o-rwx dude/photos should make sure that popolo can't access those files. Or: An alternative way would be to give popolo and empty chroot home ...


1

First when you add your self to a group it does not apply immediately, easiest thing is to logout and back in. Then there is write permissions of data files (as mentioned already by some of the comments). However the solutions are not good for security. Add a group for the game, do not add any user to this group. Make the game executable by anyone chmod ...


1

effective permissions are formed by ANDing the actual (real?) permissions with the mask.  Since the mask of your file is rw-, all the effective permissions have the x bit turned off.


1

Permission to remove and rename a directory is determined by its parent's permissions, not its own (just like other files). Just set the permissions on the directory to what you need and make its parent -w. Depending on your use case you may want to make the directory sticky +t as well - then users can't move around others' files, only their own.


1

If you fiddled with your home directory, you needed root to get at the /home directory that contains it. Possibly your home now contains some stuff owned by something other than you, that the sudo obviates. An aggressive approach might be "sudo chown -R myname:users ~myname" A more cautious person might do "find ~myname ! -user myname" to look for such ...


1

When a program wants to read or write to a file, it needs to call the system call open() for the file first. One of the arguments to the call specifies which operations the program wants to be able to do. It the program indicates it wants to read or write the file, and the process does not have the perspective for the operations, the open() call ends up in ...


1

You gave an unneeded space after the slash. Your terminal problems will be fixed by a reboot. These permissions are long in a ramfs-based filesystem which will be reconstructed on every reboot. But warn: you system is currently probably unbootable, thus after a reboot you started probably on a rescue system. If you don't have a backup, you need to know, ...


1

If you access the disk using a filemanager then the partition is mounted in: /run/media/<username>/<label or uuid> Only the user which used the filemanager has permissions to this partition. To make the partition visible to others, you'll need to add it to /etc/fstab. For example: /dev/sdb1 /media/mystuff ext4 defaults 1 2 ...


1

The directory /tmp must have the permissions 1777 = rwxrwxrwt, i.e. everybody can read, write and access files in the directory, and (t = sticky bit) files may only be deleted by their owner. A lot of things will stop working if this isn't the case, sometimes in bizarre ways. sudo mkdir -m 1777 /tmp or sudo mkdir /tmp && sudo chmod 1777 /tmp ...


1

the ownership is preserved, but probably you dont have the same users in both enviroments. check the user id of by example user www-data in both servers and compare it. you may see another name, but the id will be the same


1

rsync can't preserve ownership if it's being run by a non-root user on the destination system, because only the superuser is allowed to create files that are owned by someone else. Instead of using rsync create a tar file on the intermediate system. Then when you restore it on the ultimate target system, you can do so as root in order to give the original ...


1

Your file has the immutable extended attribute set, which is why you can't delete it. lsattr returns the extended attributes on the file: $ lsattr model/DailyUpdateClass.class -u-Diad--j------ DailyUpdateClass.class You will need to decipher all of the letters (-u-Diad--j) The man page for lsattr will tell you to look at the man page for chattr for a ...


1

A user can not delete readonly snapshots directly, but he can make them writeable first and then delete them. For this you need to use the btrfs property command: btrfs property set -ts /path/to/snapshot ro false If the user is the owner of the snapshot, this should make it writeable and therefore deletable.


1

Your understanding is pretty much correct. A better way to think of the execute permission is that it allows you to do things with a file or directory name in the directory (other than just reading the name itself). Most of those things involve translating the name to an inode, but it also includes creating new names and removing existing names. Write ...



Only top voted, non community-wiki answers of a minimum length are eligible