Tag Info

New answers tagged

1

The answer in the Permissions Create a group and add your users to it. Create the folder structure Put the files in the folders Set the proper write permission on the files so the group can read write and modify Make the folder structure read only, you'll need to do this on every folder Disable inherit permissions folder options -> Security -> Advanced -> ...


0

If you provide read permission for the user to the logs directory, this does not ensure that the user has read permission (or any other permission) to the files inside it. You need to provide read permission for this user to each log file separately. Most probably, this is the reason you need to add the reader to the specified groups, it is because those ...


0

In your script that creates the directories/files, add the 'chown developer' at the end to make the newly created files owned by the correct user. This seems much preferable to having root-owned files writeable by non-root users. However, I don't quite understand why ACLs aren't doing the right thing; if you have set the 'default' ACL, that should ensure ...


0

I know a snort(https://www.snort.org/) box can be set up to accomplish this when its configured to act like an IPS. It will allow you to create very granular rules including protocol types and IP ranges. I have done it once in a lab environment, it wasn't the simplest thing to set up and it may be overkill for your requirements. But its free and it will ...


0

To use POSIX ACLs with NFS, you had to use NFSv3. NFSv4 ACLs are way different that POSIX ACLs. The first one are set using the very specific nfs4_getacl and nfs4_setacl, while the latter are configured with the standard getfacl/setfacl binaries. In short, NFSv4 ACLs have nothing to do with POSIX ACLs (they are much more similar to the CIFS ACLs used in ...


0

You must use getfacl on the NFS server (because you query the local file-system), and use nfs4_getfacl when you are on the NFS client. NFSv4 ACL and Linux ACL acl(5) are completely different standard ! The Linux NFS server will translate the ACL back and forth. Read the post No acl on nfs mount in RHEL6?.


0

Are you absolutely sure that you have used mkdir somedir/somedir and not used the -poption like mkdir -p somedir/somedir ? Because mkdir -p has a nasty bug on distribution <= 2014 (coreutils < 8.22), see Conflicts between ACLs and umask The ACL entries applicable for subdirectories are default: and mask: $ getfacl somedir/ default:group:user1:r-x ...


1

The ACL are used and active over NFS. Use the command nfs4_getfacl to show the ACL on an NFSv4 mount: $ nfs4_getfacl /tmp/test A::OWNER@:rwatTnNcCy A::alice@nfsdomain.org:rxtncy A::bob@nfsdomain.org:rwadtTnNcCy A:g:GROUP@:rtncy D:g:GROUP@:waxTC A::EVERYONE@:rtncy D::EVERYONE@:waxTC The reason why the ACL look so different compared to Linux ACL? Because ...


1

This is a typical job for ACLs :-) Your example $ mkdir /tmp/foo Set the permissions for the directory itself $ setfacl -m g::rwx -m o::rx /tmp/foo Set the permissions for the newly created directory and files in that directory. $ setfacl -m default:g::rwx -m o::rx /tmp/foo Test $ mkdir /tmp/foo/bar $ touch /tmp/foo/bar/baz.py $ ls -ld ...


1

It was a bug with gnu mkdir (#14371), it was fixed in coreutils 8.22. affected: Debian Wheezy 7, RHEL/CentOS 5 and 6 are affected (and probably Ubuntu Trusty 14.04) not affected: Debian 8 Jessie, RHEL/CentOS 7 (and probably Tbuntu Utopic 14.10) There are a few workaround. Workaround #1: wrapper (already suggested by Mark Wagner) Since mkdir works you ...


3

The reasoning for this question is questionable ... To critique your desired solution of creating a new user -- even if other root users can't change new-user's password they don't need to since root can read any file or change the file permissions of the file -- they don't ever need to "be" that user." I you have terabytes of data you want to prevent ...


1

I suppose you could set an immutable extended filesystem attribute on /etc/shadow. That will prevent all changes to passwords, until the root user undoes the immutable bit. The command is "chattr +i /etc/shadow" If you are provisioning root access to a professional sysadmin you're supposed to assume that they won't change the password if you ask them not to ...


2

Ultimately if you give someone root access to your system, you give them everything on the system, that's why it is important for you to trust people you give root to.



Top 50 recent answers are included