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

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

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

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 ...


2

tl;dr Access is determined by the user who is running application, and sudo runs applications as different user. Full version: How does the OS know that a command needs sudo? It doesn't know. UNIX manages permissions not on application level but on filesystem level: permissions are granted for users to access specific files. Applications then are run ...


2

You can do this using udev. Create a file in /etc/udev/rules.d with the suffix .rules, e.g. local.rules, and add a line like this to it: ACTION=="add", KERNEL=="i2c-[0-1]*", MODE="0666" MODE=0666 is rw for owner, group, world. Something you can do instead of, or together with that, is to specify a GID for the node, e.g: GROUP="pi" If you use this ...


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

What about: sudo rm directory/filename or: su -c "rm directory/filename" depending on your distro and/or setup. You are giving yourself a temporary root for the duration of the above commands and as root is almighty on Unix/Linux you are allowed to do anything. This contrasts with MS Windows where you can remove access to the administrator account ...


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

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


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


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 ...


1

It doesn't make sense if the unix file permissions disagree to the acl entry and vice versa. Accordingly, the manual page (acl(5)) says what you ask for: CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS The permissions defined by ACLs are a superset of the permissions specified by the file permission bits. There is a correspondence ...


1

The reason for EPERM (the permission denied error ) is here: drwxr-xr-x 5 www-data www-data 4096 juil. 30 13:47 . The directory where you are trying to create a file (in other words change contents of the directory-file) is writeable only for user www-data, which you are not. Either mark the directory as writeable for the group, change the user to ...



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