Tag Info

Hot answers tagged

9

Note the . at the end of the permissions (drwxrwxrwx.): that means there's an SELinux context involved. You need to get that right for your user to be able to list the contents of the directory. To see the contexts for your directory, run sudo ls -alZ (the -Z option shows the SELinux contexts required). The CentOS wiki has a good page on SELinux. You'll ...


4

The user pagagne will need to logout and login to his/her shell for the group to be visible in his groups. You could also check if the user has indeed been added to the group: groups pagagne


4

Your otheruser cannot access /home/myuser/bin/runmacroscript.py. The directory permissions on either or both of /home/myuser or /home/myuser/bin are too restrictive. The reason it works when you are already in the /home/myuser/bin directory is that otheruser doesn't have to traverse the directory tree to get there.


4

Restrictions are a sensible issue, and it must be defined consistently. What you can do is to define a restricted shell for the user as his default shell. For example, setting /bin/rksh (a restricted kornshell) instead of the user's predefined shell as the default shell for that user in /etc/profile. - Note: if the executable with this name is not existing ...


4

The command chroot allows you to create a restricted root for a user, this question explains the concept of chroot and how to use it. Update: Searching for chroot jail set up on digital ocean, brings up further documentation specific to their environment. Here's a couple which I think are related to what you might need. How To Configure Chroot Environments ...


4

An empty permission set can be represented with -: setfacl -dm o::- mydir This doesn't appear to be documented, so I don't know how portable it is. However, the documentation does mention that they can be specified as an octal digit (4 r, 2 w, 1 x, as in chmod), so: setfacl -dm o::0 mydir


3

Yes, he/she can write files on /tmp for instance. Regarding modification of files, that depends on the file's permissions. If all users are allowed to modify that file he/she will be able to modify that file or if he/she belongs to the other user's group and that group has permissions to do that. In the end it all depends on the permissions, so take a ...


3

You can assign the sticky bit to the working directory: chmod g+s ... That way whenever a file is created, it is assigned to that group. You can then edit the users' umask to allow group members to edit files by default.


3

TL;DR find "$dir" ! -type l -print0 | sudo -u "$user" perl -Mfiletest=access -l -0ne 'print if -r' You need to ask the system if the user has read permission. The only reliable way is to switch the effective uid, effective gid and supplementation gids to that of the user and use the access(R_OK) system call (even that has some limitations on some ...


3

You need to add PermissionsStartOnly=true to [Service]. Your user FOOd is of course not authorized to create a directory in /var/run. To cite the man page: Takes a boolean argument. If true, the permission-related execution options, as configured with User= and similar options (see systemd.exec(5) for more information), are ...


3

See Understanding UNIX permissions and their attributes for an explanation of the s. + appears after the standard permissions, and is one of the possible characters used to indicate that the file has "alternate access methods". With GNU ls the character can be blank (the default), . to indicate a security context applies to the file, or + to indicate any ...


3

There are few things you could do here: First check whether you have a Dropbox daemon running. Check the attributes of the Dropbox folder using lsattr and if the folder is not editable, then change its attributes to editable using chattr. UPDATE As OP has reported in the comments, the .dropbox-dist folder contains i attribute which means the folder ...


2

The parent directory of temp2 and temp3 is where the issue lies. Your atlas group has read permissions on the parent directory and you need read AND execute in order to see the files and their permissions. if you're in the directory with temp2 and temp3 you can fix the issue with the following command: sudo chmod g+x .


2

Even assuming you meant chmod g=u rather than chmod 770, it may well break some of the PAM security modules, including those that manage logins. It will break ssh logins, as ssh checks permissions on $HOME and all parent directories. If, as you suggest in your comments, you simply want to avoid using sudo there are some options that spring to mind: Login ...


2

This is a configuration that allows members of a group, acltest, to create and modify group files while disallowing the deletion and renaming of files except by their owner and "others," nothing. Using the username, lev and assuming umask of 022: groupadd acltest usermod -a -G acltest lev Log out of the root account and the lev account. Log in and become ...


2

The find manual page explains: -perm +mode Deprecated, old way of searching for files with any of the per‐ mission bits in mode set. You should use -perm /mode instead. Trying to use the `+' syntax with symbolic modes will yield sur‐ prising results. […] So yes, they're the same thing, but you should use ...


2

The rsync command doesn't have a mechanism for handling this directly, so I would use a different approach. I would scan the source filesystem tree, collecting the usernames (and groups) of all files present there: # List of usernames owning files under 'src' find src -printf "%u\n" | sort -u | tee /tmp/src.users # List of group memberships for files under ...


2

You can chroot the software into a bind mount setup where these directories are mounted read-only. mkdir /foo mount --bind / /foo mount --rbind /dev /foo/dev mount --bind /proc /foo/proc mount --bind /run /foo/run mount -t tmpfs tmpfs /foo/tmp mount --bind /sys /foo/sys mount --bind /usr/bin /foo/usr/bin mount -o remount,ro /foo/usr/bin chroot /foo rpm … ...


2

You can use find for that: find / -type d -group web -exec chmod g+rx {} + This is slightly inefficient as it will also set group to rw for those that already have those set. You can also have find check on some of the permission bits with -perm /mode and negate that match.


2

Above and beyond the question of whether it's a good idea (it opens up the potential for a non-root user to fill up the root filesystem, causing havoc), you could accomplish this in several different ways: chmod a+w / -- to give "other" write permission chgrp somegroup /; chmod g+w /; usermod -G somegroup user -- to change the group ownership of / to a ...


1

The permissions for group take priority over permissions for other. And in turn, permissions for user take priority over both. You're not the owner but you are in group1, so those are the permissions that are checked. Generally, permissions rarely become less restrictive when going from user to group to other. In your scenario, if you want members of group1 ...


1

If you use acls, the classic group permissions turn into the so called mask,which determines the maximum permissions you can effectivly give per setfacl, eg. ls -k shows -rw-r--r--+ root root and you have setfacl -m g:users:rw because the mask is only read getfacl will show you : group:users:rw effective r So set group to rw or rwx by classic chmod and ...


1

Your ls output shows with a + sign in the modes that your files and directories are using ACLs. drwxr-xr-x+ ... These may be restricting your accesses. List the acl permissions with getfacl <file or directory> and remove them with setfacl -b <file or directory> then check again. EDIT from OP: Indeed, that is it - here is a snippet of ...


1

The behavior of lsblk changed in util-linux at version 2.25.2-4: util-linux (2.25.2-4ubuntu2) vivid; urgency=low Add missing libudev-dev build-dependency. This makes the "LABEL" information of lsblk available for non-root users (closes: #776905) -- Michael Vogt Tue, 03 Feb 2015 09:06:46 +0100 @muru did additional testing to ...


1

The man page for GNU find says: -perm /mode Any of the permission bits mode are set for the file. ... and -perm +mode Deprecated, old way of searching for files with any of the permission bits in mode set. You should use -perm /mode instead. Trying to use the ‘+’ syntax with symbolic modes will yield surprising results. ... and gives ...


1

I spun up some fresh CentOS 6 and 7 vm's and was able to recreate the exact behavior you showed. After doing some digging, it turns out that this is actually a change in the kernel regarding default behavior with respect to hard and soft links for the sake of security. The following pages pointed me in the right direction: ...


1

i solved my problem by this way : sudo addgroup exchangefiles Create the chroot directory sudo mkdir var/www/GroupFolder/ sudo chmod g+rx var/www/GroupFolder/ Create the group-writable directory sudo mkdir -p var/www/GroupFolder/files/ sudo chmod g+rwx var/www/GroupFolder/files/ Give them both to the new group. sudo chgrp -R exchangefiles ...


1

It seems to me that most people create a directory named mysql inside of /var/log, change the owner of this folder to the mysql user. sudo mkdir /var/log/mysql sudo chown mysql:mysql /var/log/mysql That should do it. Be sure to update the server's logging location and restart it. After you've tested re-enable mysql's apparmor profile.


1

It sounds to me like you have done everything right, so I would suggest filing a bug against aufs. PS: Kontrollfreak has done that already, and the fix is to use the dirperm1 mount option, according to http://sourceforge.net/p/aufs/bugs/21/#1293 . Thanks for your research @Kontrollfreak .


1

From the manpage of the syscall chflags(2): SF_IMMUTABLE The file may not be changed. SF_NOUNLINK The file may not be renamed or deleted. [...] UF_IMMUTABLE The file may not be changed. UF_NOUNLINK The file may not be renamed or deleted. The flags prefixing with SF_ may only be set or unset by the super-user. The others prefixing with UF_ may ...



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