Tag Info

Hot answers tagged

14

For the purposes you have described, the OS doesn't decide whether you need sudo to initially run the program. Instead, after the program starts running and then tries to do something that is not permitted by the current user (such as writing a file to /usr/bin to install a new command), the OS prevents the file access. The action to take on this condition ...


10

Sometimes the "Permission denied" message is due to filesystem permissions denying you write access, for example. The executable/tool simply checks if it the filesystem grants you enough permissions to do what you're about to do and throws an error if it's denied by the filesystem. Other times, the tool itself will check your user ID before allowing you to ...


8

There are multiple ways of accomplishing this. 1. Add your user to the group that owns the device Generally in most distros, block devices are owned by a specific group. All you need to do is add your user to that group. For example, on my system: # ls -l /dev/sdb brw-rw---- 1 root disk 8, 16 2014/07/07-21:32:25 /dev/sdb Thus I need to add my user to ...


8

Use the -perm test to find in combination with -not: find -type d -not -perm 775 -o -type f -not -perm 664 -perm 775 matches all files with permissions exactly equal to 775. -perm 664 does the same for 664. -not negates the test that follows, so it matches exactly the opposite of what it would have: in this case, all those files that don't have the ...


6

If it were setgid root then the agent would run as group root, which likely has broader permissions than the user it started as. That could be a security risk; at the least, running something as root unnecessarily is a red flag (even the group) and requires extra attentiveness. Setting the group ownership to nobody, which is a group that shouldn't have any ...


5

No you're unable to find out whom has access to sudo rights if you yourself do not have access directly. You could possibly "back into it" by seeing what users if any are members of the Unix group "wheel". Example This shows that user "saml" is a member of the wheel group. $ getent group wheel wheel:x:10:saml Being a member of the "wheel" group ...


5

The issue is indeed that the Finder's way of modifying permissions doesn't only affect the indicated bits as one might think. For some reason it zeroes out the first octal of the file's mode and it leaves the executable bits untouched. So, some vital programs get their setuid/setgid and sticky bits stripped off which makes them either useless or behave ...


5

You could create per directory limits by mounting filesystem image files on subdirectories in /home. This won't disable /home, but it will solve your problem in so far as it will prevent people from writing more than a fixed amount. A filesystem image file works like this: Create an empty file of a fixed size, e.g. 100 MB: dd if=/dev/zero ...


4

Someone evidently moved a regular file to /dev/null. Rebooting will recreate it, or do rm /dev/null; mknod -m 666 /dev/null c 1 3


4

type vfat There's your problem. vfat knows nothing about Linux permissions. It's not an issue of USB mounts, but of file-systems used. Oh: and to answer your question - no, it's not a problem.


4

Once you hit a directory that's not executable, find tries to go into it, but it can't because, well, it's not executable. You need to tell it not to try by using -prune. And put that condition first, so it's not short-circuited. find . '(' '(' -not -executable ')' -and -type d -and -prune ')' -or \ '(' -not -readable ')' -or \ '(' -not ...


3

Without the ability to use sudo your options become limited to essentially 2. Method #1 You can either put the users into the same Unix group (/etc/group) so that they're able to access the same files & directories. Example $ more /etc/group somegroup:x:1001:adminuser,nobody You then need to set the parent directory that contains this file like ...


3

Your permissions issue is not a file permissions issue but SELinux disallowing the sendmail executable from accessing files on the filesystem in a specific location. Your best friend for dealing with these is to use the SELinux troubleshooter GUI. $ sealert -b     You'll then want to follow the advice to add the necessary contexts to your ...


3

Edit: See Gilles' answer for a way to fix the permissions and ownerships instead of trying to adjust based on my (for you probably incomplete) list. There are a few files that are normally owned by another group. Excerpt from my system: $ lsb_release -d Description: Debian GNU/Linux 6.0.9 (squeeze) $ find /usr/bin -not -group root -exec ls -g {} \; | ...


3

su and sudo are privileged programs. su changes (after successful authentication) the real and effective user and group id to that of the user you su to. Thus, su is similar to login. Note that su can be used to change to any user, not just root. sudo also changes the real and effective user and group ids. Up to this point su and sudo are similar (but ...


3

See the Wooledge wiki on tests and conditionals: -w FILE: True if the file is writable by you. So, you could test it with: [[ -w "$file" ]] If you aren't using bash, you could equally use [ -w "$file" ]


2

The point of making ssh-agent setgid is to increase security by making the process impossible to debug, so that even a process running as the same user can't dump keys from memory. ssh-agent should not in fact have additional privileges. In case there is a vulnerability in ssh-agent, if it is setgid to some group, this confers the user the privileges of ...


2

As I searched through the list of unanswered questions for ones that I might be able to answer, I saw this question’s title and I figured that it might be an issue with file attributes. As detailed in the question’s comments, the immutable attribute had been set and @slm posted the solution: sudo chattr -i /var/www/update However, @slm also asked a very ...


2

Reset all UIDs and GIDs: for i in $(rpm -qa); do rpm --setugids $i; done Reset all permissions: for i in $(rpm -qa); do rpm --setperms $i; done Try to restart: service sshd restart Does that help?


2

You need setfacl. setfacl -R -m ${other_user}:rwX,d:${other_user}:rwX I added default (d) as this us usually best to keep it correct. -R is recursive I think you need to do something with x permission as the named user and you can add directories -- I added X, I thing that is correct.


2

If you know what directories were affected -- looks like you do -- you can run, e.g.: chmod -R 755 /usr/bin -R is recursive. This should be fine for everything in a bin directory. If chmod itself is affected, you could try this on it, or else boot the box with a live CD and use that.


2

Let's start with some "history". /usr/local is typically used to store user programs/data that were not installed with the base operating system. Commonly, when you make programs from source using automake, they will install somewhere under /usr/local. Because the main operating system itself doesn't rely on this directory, permissions are really up to the ...


2

Yes, all files under /usr should be owned by root, except that files under /usr/local may or may not be owned by root depending on site policies. It's normal for root to own files that only a system administrator is supposed to modify. There are a few files that absolutely need to be owned by root or else your system won't work properly. These are setuid ...


2

First the terminology. chmod is a program (and a system call) which alows changing permission bits of a file in a filesystem. sudo is a special program that allows running other programs with different credentials (typically with elevated privileges, most usually those of the root user). su is similar but less (read "not") configurable than sudo - most ...


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


1

This should fix the issue (as root): rm /dev/null mknod /dev/null c 1 3 chmod 666 /dev/null


1

Change the directory to allow listing file entries and write to it: chmod +rwx . Do not allow reading the files themselves: chmod -r * This works only for existing files. For new files use umask before starting your server: umask -- -r Read the man page of the command for more details.


1

Your new user new_username will not have root privileges after editing the sudoers file. This change only allows new_username to run sudo in order to run a task with superuser privileges: $touch testfile $chown new_username testfile chown: changing ownership of 'testfile': Operation not permitted $sudo chown new_username testfile [sudo] password for ...


1

Since you have "Permission denied" on a directory, it is likely that the directory does not have execute permissions. Similarly, to traverse a directory tree to get at a file, you would need execute permissions on each directory in between the root and the file (hence the same error for the other command). Try setting the execute permissions on the ...


1

try to mount the filesystem you are trying to set acls on with acl options. something like this in fstab: /dev/rootvg/filesystem /filesystem ext4 defaults,acl 1 2



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