I have the following lines in my haproxy.conf:
acl valid_domains hdr(Host) -i mysite.com images.mysite.com docs.mysite.com admin.mysite.com
redirect location http://mysite.com/invalid_domain if !valid_domains
How do I match any subdomain?
I tried:
acl valid_domains hdr(Host) -i *.mysite.com
and:
acl valid_domains hdr(Host) -i [a-z]+.mysite.com
... But neither worked.
Thanks
I'm trying to give full access (read, write) to a specific folder to all users on Windows 7. The problem is that I don't know how to do that using icacls.
A common way to set up a directory for file sharing within a group, is:
$ mkdir foo
$ chgrp felles foo
$ chmod g+ws foo
$ setfacl -m group:felles:rwx foo
$ setfacl -dm group:felles:rwx foo
This ensures that any files created in foo is readable and writable by the group felles:
$ umask
0022
$ echo hi > foo/bar
$ ls -l foo
total 4
-rw-rw-r--+ 1 bhm felles 3 2010-09-23 00:18 bar
However, if you copy a file into foo, the default ACLs are not applied:
$ echo you > baz
$ cp baz foo/
$ ls -l foo
total 8
-rw-rw-r--+ 1 bhm felles 3 2010-09-23 00:18 bar
-rw-r--r--+ 1 bhm felles 4 2010-09-23 00:19 baz
$ getfacl foo/baz
# file: foo/baz
# owner: bhm
# group: felles
user::rw-
group::rwx #effective:r--
group:felles:rwx #effective:r--
mask::r--
other::r--
Why does this happen, and is there a way around it?
(Moving a file into the directory does not respect either ACLs or group ownership, but I can understand why: you might not want the permissions of a file to change simply because you change its name.)
As anyone that has dealt with file server permissions is aware, NTFS has an interesting design feature/flaw known as the Move/Copy problem.
As explained in this MS KB article, the permissions for a folder or file do not automatically inherit from the parent if the folder is moved and the source and destination are on the same NTFS volume. The permissions are inherited if the folder is copied or if the source and destination are on different volumes.
Here is a quick example:
You have two shared folders on the same NTFS volume called "Technicians" and "Managers". The Technicians group has RW access to the Technicians folder and the Managers group has RW access to the "Managers" folder. If someone has access to both and they move a subfolder from the "Managers" folder to the "Technicians" folder, the folder that is moved is still only accessible to users in the "Managers" group. The "Technicians" group cannot access the subfolder even though it is under the "Technicians" folder and should be inheriting permissions from the top.
As you can imagine, this causes support calls, tickets, and wasted cycles on resolving these end user issues, not to mention the rats nest of permissions that you can end up with if users are often moving folders between different secured folders/area on the same volume.
The questions are:
What is the best way to workaround this NTFS design flaw and how are you handling it in your environment?
I know the linked KB article talks about some registry keys to change the default behavior of Windows Explorer but they are client-side and requires the users to have the ability to change permissions which I would think in most environments is a non-starter if you want to keep control over your file server permissions (and your sanity as a sysadmin).
Every so often I run into a file that I need to take ownership of. I normally use cacls for changing ntfs permissions, but it doesn't seem to do ownership. Under *nix I would run something like chown me:me <file>. Is there a windows equivalent to chown?