Tag Info

Hot answers tagged

10

Actually, I believe the question was not about the (standard) file permission bits, but extended ACL information (see setfacl(1) or acl(5)). To my knowledge, the unmodified GNU tar ignores ACL information. (The man page for GNU tar 1.15.1 as shipped with RHEL 5.2 mentions switches --acls and --no-acls, but I haven't gotten them to work.) However, the star ...


6

This will probably get closed for soliciting opinions or being too broad but I'll do my best. "UNIX ACL" is a really indirect way of referring to it. I'm supposing you mean POSIX-style ACL's. The chief drawbacks there are with the lack of expressiveness in the number of operations you can specify since it just extends the traditional read/write/execute ...


5

This is kind of a broad topic and a little too much to cover here. I'll refer you to the POSIX Access Control Lists on Linux whitepaper put together by Andreas Grünbacher of the SuSE Labs. It does a pretty good job of covering the subject and breaking it down so you understand how ACLs work. Your example Now let's take a look at your example and break it ...


4

DAC == Discretionary Access Control, http://en.wikipedia.org/wiki/Discretionary_access_control MAC == Mandatory Access Control, http://en.wikipedia.org/wiki/Mandatory_access_control ACL == Access Control List, http://en.wikipedia.org/wiki/Access_control_list The ACL specifies the controls to be applied by the method of control, DAC or MAC. MAC is explicit, ...


4

The + at the end indicates the presence of an access control list. An ACL on a file gives additional users or groups specific permissions, in addition to the traditional unix permissions which only distinguish between the owning user, the owning group and others. You can use getfacl to see the ACL on a file and setfacl to set it. cp -a would copy the ACL if ...


4

With normal unix permissions, you can't do this. With ACLs you can (or should be able to). You need to be using a filesystem that supports ACLs. Most modern linux filesystems do. The basic command is setfacl In your example, if group B owns directory /B you would add access rights for group D as follows: setfacl -m group:B:rwx,group:D:rwx /B This is ...


4

Here are 2 ways to do it: mount Using mount's -v switch: $ mount -v | grep /home/sam mulder:/export/raid1/home/sam on /home/sam type nfs (rw,intr,tcp,nfsvers=3,rsize=16384,wsize=16384,addr=192.168.1.1) nfsstat Using nfsstat -m: $ nfsstat -m | grep -A 1 /home/sam /home/sam from mulder:/export/raid1/home/sam Flags: ...


4

This is because the permissions are checked at every level to get to a directory, not just the target directory. You can give a user or group permission to pass though a directory without being able to access what is inside it by setting the execute bit for that user or group without setting either the read or write bits. For example: chmod 710 /home/$USER ...


3

Is there any approach out there which replaces this concept (probably per mount) with something simpler, where files inherit permissions from their containing directories by default? Yeah, they're called default ACLs: [root@ditirlns02 acl-test]# setfacl -m d:u:jadavis6:rwx --mask . [root@ditirlns02 acl-test]# getfacl . # file: . # owner: root # ...


3

You'll notice the "effective" comment that getfacl is throwing out at you. The issue is that permissions are calculating so that "app" isn't getting the write bit set. That's happening because the mask on the file is set to read-only. The mask is used to limit the amount of permissions that could possibly be given out on a particular file or directory. An ...


3

Your default ACLs replace the umask, which specifies not default permissions, but maximum permissions for creating new files. In this case rwxrwxr-x. Then your application calls open or creat with the permissions it wants. Just about all applications will ask for rw-rw-rw- for files. You can see this by running strace, e.g. $ strace -e trace=file touch ...


3

To be honest, the first thing I did with my RHEL6 OpenLDAP installation was to revert back to the legacy slapd.conf file-based configuration, since it's much more amendable to things like version control and Puppet. However... If you're familiar with the legacy configuration mechanism, you can set up your ACLs in a slapd.conf file and then use slaptest to ...


3

(I assume you're working on Linux, the workings of ACLs differ between unix variants.) cp doesn't do anything special when you copy the file; it creates the file with the mode of the original file, masked by the mask of the directory. Since cp doesn't do anything to the file's mask, the mask ends up being the intersection of the directory mask (rwx) and the ...


3

If you've quoted your command accurately as: find /opt/path -exec setacl -d user:myUser{} ';' you are missing a crucial space: find /opt/path -exec setacl -d user:myUser {} ';' The former invokes undefined (or maybe implementation-defined) behaviour from find; it might or might not expand the file name when the {} is not in an argument on its own. But ...


3

The exact details may depend on the filesystem, but conceptually, yes, the ACLs are metadata stored in the file inodes just like traditional permissions, dates, etc. Since the size of ACLs can vary, they may end up being stored in separate blocks. However the details only matter if you're designing a filesystem or programming a filesystem driver.


3

from man getfacl: The output format of getfacl is as follows: 1: # file: somedir/ 2: # owner: lisa 3: # group: staff 4: # flags: -s- [...] Line 4 indicates the setuid (s), setgid (s), and sticky (t) bits: either the letter representing the bit, or else a dash (-). This ...


3

I've done this before using rsync -aHAX --delete remembering to add the -n and -i flags. This is slightly counterintuitive, but bear with me. The main rsync command is what you would need to sync the two directories together. But -n -i causes it NOT to sync (i.e. do a dry run) and just print out what it would have done and why. It isn't fantastic to parse, ...


3

In general, UNIX permissions are not that granular. A person with write access to a directory can create and delete files -- both operations write to the directory file. selinux would allow you to specify such a policy. (it'd be akin to swatting flies with a hammer, 'tho)


2

The "sender", as Exim sees it is the envelope-from address, and that was in domain returns.groups.yahoo.com. Once I put that domain (completely; groups.yahoo.com doesn't work, neither does yahoo.com) into my local_sender_whitelist, the ACL worked. It had worked during testing because I had used the envelope-from address of yahoogroups.com, the same as the ...


2

I have noticed this pattern, but don't think much is getting through. Try this warn message = Message identified as spam. If you think this is wrong, \ get in touch with postmaster log_message = Possible spam with ${h_to:} as both from and to !senders = ${if exists{CONFDIR/local_sender_whitelist}\ ...


2

Procedure is very similar to procedure of changing password that I described in another question. There are also two ways. 1) Editing config file. You need to find config file of your backend. Each ACL is defined as value of olcAccess attribute. Syntax of ACL is identical as in "normal" slapd.conf file, but at the beginning of each ACL you must insert ...


2

If you're looking for a simple-to-use yet powerful solution, I'd recommend rdiff-backup. Basically, it makes a copy of a source directory to a destination directory but it also saves additional information so you can go back in time to whenever you want. And, of course, it preserves symlinks, special files, hardlinks, permissions, uid/gid ownership and ...


2

Do all of your users have a single group in common? For example, on some systems the staff group is provided for use as the global group. If you create your users' home directories so they belong to this global group, just setting the read permission on them will allow all members of the group (i.e. everyone) to see other people's files. Note, though, that a ...


2

As Ulrich says, you can't do this with traditional groups. Your file permissions are limited to one owner, one group, and "everyone else". You may be able to accomplish your access requirements by having users in multiple groups, but even then limits 1 and 3 are mutually exclusive, presenting a problem. The solution you need is based in either LDAP or ...


2

If we have a look at the acl(5) man page, we see: 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 between the file owner, group, and other permissions and specific ACL entries: the owner permissions ...


2

Here's what's probably happening: You're creating a /tmp/test/.hg directory via 'hg init' presumably without group permissions due to a restrictive umask You're recursively setting ACLs, but not recursively setting traditional permission bits to match Mercurial copies the traditional permission bits on /tmp/test/.hg/ when creating new files under .hg Thus, ...


2

I found this example, titled: ACL and MASK in linux. In this article the following examples are demonstrated which I think help to understand how ACL's and umask interact with each other. Background When a file is created on a Linux system the default permissions 0666 are applied whereas when a directory is created the default permissions 0777 are applied. ...


2

There is nothing special about a user's home directory that would make permissions different. After all, permissions are handled by the kernel, and the kernel has no concept of home directory. A user's home directory usually belongs to that user. An ACL for the owner of the file is ignored, the classical permission bits for the owner (set by chmod u=…) ...


2

Rather than muck with the permissions of /var/log I think I'd go the direction of giving these users sudo rights for a limited set of commands. Setting up sudo access You can create a command alias in the /etc/sudoers files like so: Cmnd_Alias RDONLY_VARLOG = tail /var/log/messages, tail /var/log/maillog, ... Then grant users access to this command ...


2

With setfacl you can set default permissions but not default owner/group for newly created files. To get new files to be owned by a specific user, you'd need a setuid bit that works like the setgid bit on directories. Unfortunately that is not implemented. With setfacl you can do something which is nearly equivalent in most scenarios: You can set an ACL ...



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