Bash-on-Ubuntu-on-Windows supports case-sensitive file paths. This means that I can create two files or directories with names only differing in capitalization. I have issues accessing those files, though.
Running
bash -c "touch Magic ; mkdir magic ; echo Secret! > magic/secret"
Creates a file names Magic, a directory named magic and a file names secret in that directory.
bash -c "ls -lR" yields
.:
total 0
drwxrwxrwx 2 root root 0 Aug 23 10:37 magic
-rwxrwxrwx 1 root root 0 Aug 23 10:37 Magic
./magic:
total 0
-rwxrwxrwx 1 root root 8 Aug 23 10:37 secret
(I am not sure why I get root, as it is not the default user, but that does not seem relevant to my question.)
Windows Explorer shows:
Now, while bash can easily access the magic/secret file in the directory, Windows seems to treat both the directory and the file as one and the same. So double-clicking the directory I get a "directory name invalid" error
Same goes for using cd, as I get The directory name is invalid. printed out.
Are there any APIs that allow me to access those case-sensitive paths, or create them? It seems that regular Windows APIs ignore character case completely when accessing existing files.
Case-sensitive paths can be used on Windows with NTFS, but it requires a bit of extra work.
First, case-sensitivity must be enabled system-wide. This is done by setting the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\ dword:ObCaseInsensitive registry value to 0, then restarting the system.
I found this part here.
Once case-sensitivity is enabled, it is possible to use CreateFile to with case-sensitive paths. To do that, you have to pass the FILE_FLAG_POSIX_SEMANTICS as part of the dwFlagsAndAttributes parameter. From msdn:
Access will occur according to POSIX rules. This includes allowing multiple files with names, differing only in case, for file systems that support that naming.
I found this part in this answer.
By setting the registry setting and the CreateFile flag, I was able to access case-sensitive paths.
Related
I had I had a problem in starting the LaunchAgent and googled a lot and found multiple methods to troubleshoot, Noting them all down here in one place for the benefits of others
1) Ensure that after agents are copied in /Library/LaunchAgent folder reads as following.
-rw-r--r-- 1 root wheel 798 Jun 5 11:52 /Library/LaunchAgents/com.mycompany.myproduct.LaunchAgent.plist
(When you manually copy these files for debugging, you may have manually change these attributes using chown and chgroup commands).
2) Ensure that the path given in plist-> ProgramArguments is correct. (note that space is not required here)
3) Ensure that execution permission exists for file specified in "launchAgent plist->ProgramArguments"
4) check RunAtLoad attribute
5) Ensure that WatchPath file is present, please check if the the WatchPath need need any parameterization like /path/dir1/dir2/productname%BUILDNO%.trigger
6) if there is a file com.mycompanynewname.MyProductLaunchAgent.plist in the folder it may conflict with com.mycompanyoldname.MyProductLaunchAgent.plist
7) Look for /var/log/system.log for launchctl specific logs.
8) Read more about how LaunchDemon and LaunchAgent works and Apple documentation and http://www.launchd.info/
I am really new to Bash Scripting so please bear with me if this question sounds stupid. I am also not too sure what to search on the internet.What should I do if I need to write a shell script to list any directory where one user's home directory can be modified by some other user? I am not able to understand what this 'modified by some other user means'.Please help. Thanks !
The very short answer to your question is: no script needed, simply:
ls -al /home
That will list for you all users and the respective permissions for each users home directory. Linux file permission are controlled by 10 bits that represent who has access and what, if any, special permissions are associated with a given file. The permissions bits are usually represented for discussion as drwxrwxrwx. The first, or special, bit meaning is as follows:
_: (unset) indicates a regular file with no special properties
d: directory,
l: link,
s: the directory is setuid/setgid
t: sticky bit
The next nine bits rwxrwxrwx (3 sets of rwx) control the access the owner group world has to the file in question. So who is the owner group or world? Let's look at an example from ls -al /home:
drwxr-xr-x 15 deborah users 4096 Mar 11 2011 deborah
Looking at the information we can separate the 10 bits and information as follow:
d rwx r-x r-x .. deborah users ..... deborah
| | | \ \ \
owner | world owner group filename
group
Above the special permission bit is a d which indicates that the filename (at the far right deborah) is a directory. The first set of 3 bit specifies that the owner (deborah) has read, write and execute permission on the file. Similarly, the next set of 3 specify that the group (users) has read and and execute permission but no write permission. NOTE: with a directory, the execute bit also control whether the (owner, group or world) can descend into the directory. In like manner, the world (everybody) has the same permission as group (users).
To manipulate the bits, you use the chmod (change mode) command. To manipulate the user or group, you use the chown (change owner) command. The chown command has simple basic usage, just specify the new owner and group separated by a colon :. For example to change the file shown above to be owned by user david and group samba the command would be chown david:samba filename
There are two ways to change the permissions or (mode) with chmod. You either specify the octal equivalent for special bit and the 3 sets of owner, group and world bits at once numerically. Example: to make the directory rwx for the user and group you would issue the command:
chmod 0775 filename # to set all permissions as desired at once
The 0 simply stating no special bit settings for the directory, the first 7 indicating the binary 111 (or rwx) for the user, the second 7 indicating the same for the group and the final 5 indicating the world should have (binary 101) r_x permissions. While not always required, it is recommended to provide the leading 0 even when there will be no change to the special permission bit to remove any ambiguity.
You can also use chmod with +/-/= r, w, x (for corresponding rwx bits) for u, g, or o user, group, or owner permissions (you can shorcut using a for all). To put it all together and set the mode the same as shown above using octal bit, you would simply do:
chmod g+w filename # to add the single write bit to group 'users'
Using this method, you may be required to make multiple calls to chmod to set all permission as required, but contrast using the octal permissions, you can set all permission fields in a single call.
Obviously there is much more to it than this, but for a good introduction, this should be enough to get you started managing permissions and ownership. (obviously this post also turned out way longer than initially anticipated, enjoy).
The:
where one user's home directory can be modified by some other user?
can be:
if the user1 is in the same group as user2 AND the home directory is group-writable, or
if the user has world-writable directory
You really need understand how unix-like permissions works. (or in wider context - how ACLs works in general)
For the (partial) solution (many ways - one of them is the next):
you can get the path of home directories from the /etc/passwd file.
can read them in a cycle, (filter the /etc/passwd with the cut command), and
test, if they're writable for you (for this, read the man page about the shell builtins if and the command test alias [.
Since making a hash of a complete binary file would be far too heavy to compute in a reasonably fast time:
What are sufficient file information for hashing a file? The following lists what properties the resulting hashing should ideally have:
collision-free in respect to other files in the directory
fast
catch all file changes
As a rule of thumb, the less information we can use to create enough entropy, the better. Since the speed of retrieval for specific information may depend largely on the given environment (OS, file-IO of the language, IO of the used library, etc.), it should be disregarded here.
(This is my first attempt at a community wiki. My reason for making it one is that the information asked here is very generic but (hopefully) informative. I also would like this question to be marked as a community wiki, so it can be improved where fit. )
General Overview
Our goal here is to track as much differences between two file states while not using redundant data. Thus each informational source must be a disjointed subset of the information of the files state.
The following items represent sources of information about a file:
the name of the file
the directory-path relative to the specified document-root (aka absolute from document-root)
the files permissions
the files owner (user/group)
the last change time
the size of the file
the hostname of the machine the file resides on
the actual saved binary data
Per Item Considerations
Name of File
The name of the file is part of its absolute filesystem's path (the last bit) and as #La-comadreja said, it is unique in that no two files on a system can have the same absolute path. Using the File's name in combination with the rest of its absolute path (see directory-path for more information) is highly encouraged to avoid hash collisions with other files.
Directory-Path
While the files absolute path will be perfectly unique, it should be noted that in certain circumstances hashing the absolute path may be inappropriate. For instance, comparing the hashes of two files on different machines will most likely fail when both files do not have the identical absolute path on both machines. This becomes even more problematic on machines with different OS's and/or architectures. It is therefore encouraged to specify a document-root and resolve an absolute path from there.
Permissions
If you want to track changes to a files permissions, the tests below indicate that you would need to incoporate them into your hash directly as they do not change any other information about the file (most notably the timestamp). Note however that permissions are handled quite differently on different machines, so caution must be exercised here (for instance to use a canonical permission translation scheme).
Ownership
Ownership, just as permissions, is handled very differently across architectures and filesystems. A change of ownership does not change other information (as indicated by the tests below).
timestamp
The timestamp of a file is also something that is not unifiedly implemented across all (or at least the most common) systems. First of all, there are different timestamps on different filesystems we could be looking at: creation date, modified date, access date, etc. For our purpose the modified date is most suitable, as it is supported by most of the available filesystems [1] and holds the exact information we need: the last change to a file. However comparing files across different OS's may pose a problem, as Windows and Unix handle timestamps (in general) differently (see here [2] for a detailed article about the problem). Note that the modification date of a file changes whenever a file has been edited (disregarding edge cases), so timestamp indicates changes in file size (note that the opposite does not hold true, see file-size).
File size
The file size in bytes is an extremely good indication whether a file has been edited (except for permissions, ownership and name changes), as each edit would change the files content, thus changing its size. However this does not hold true if additions to a file are exactly as big as deletions. Thus the files timestamp may be a better indicator. Also, calculating a files binary size may be quite computation intensive.
Hostname
If one wants to compare files across multiple hosts and regard identical files on different hosts as different, then the hostname of the machine (or another suitable unique identifier for the host) should be included in the hash.
Binary Data
The binary data of the file has, of course, all necessary information to check if a file was changed. However, it is also too resource intensive to be of any practicability. It i highly discouraged to use this information.
Suggestions
The following sources should be used to compare files:
the name of the file
the directory path
the timestamp (see above for problems)
The following extra sources can be used to track more information:
permissions (see above)
ownership (see above)
hostname (when comparing across different machines)
The following sources of information should be disregarded:
file size
binary data
Tests
I did some tests on Debian checking whether changing one information would change another. Most interestingly rename, permission change, owner change did not affect a timestamp change or filesize change. (Note that these tests are currently only tested on Debian Linux. Other OS's will likely behave differently.)
$ ls -l
-rw-r--r-- 1 alex alex 30 Apr 26 11:04 bar
-rw-r--r-- 1 alex alex 0 Apr 26 11:03 baz
-rw-r--r-- 1 alex alex 14 Apr 26 11:04 foo
$ mv baz baz2
$ ls -l
-rw-r--r-- 1 alex alex 30 Apr 26 11:04 bar
-rw-r--r-- 1 alex alex 0 Apr 26 11:03 baz2
-rw-r--r-- 1 alex alex 14 Apr 26 11:04 foo
$ chmod 777 foo
$ ls -l
-rw-r--r-- 1 alex alex 30 Apr 26 11:04 bar
-rw-r--r-- 1 alex alex 0 Apr 26 11:03 baz2
-rwxrwxrwx 1 alex alex 14 Apr 26 11:04 foo
$ mv baz2 baz
$ echo "Another string" >> bar
$ ls -l
-rw-r--r-- 1 alex alex 45 Apr 26 11:17 bar
-rw-r--r-- 1 alex alex 0 Apr 26 11:03 baz
-rwxrwxrwx 1 alex alex 14 Apr 26 11:04 foo
$ sudo chown root baz
$ ls -l
-rw-r--r-- 1 alex alex 45 Apr 26 11:17 bar
-rw-r--r-- 1 root alex 0 Apr 26 11:03 baz
-rwxrwxrwx 1 alex alex 14 Apr 26 11:04 foo
Assuming all the files are on the same machine, directory path and file name should produce a unique combination because two files in the same directory cannot have the same name. Directory path, filename and timestamp of last change should capture each change.
If the files are on different machines, the machine name should be included in the directory path.
I know that it outputs the "long" version but what do each of the sections mean?
On my mac, when I type in
ls -l /Users
I get
total 0
drwxr-xr-x+ 33 MaxHarris staff 1122 Jul 1 14:06 MaxHarris
drwxrwxrwt 8 root wheel 272 May 20 13:26 Shared
drwxr-xr-x+ 14 admin staff 476 May 17 11:25 admin
drwxr-xr-x+ 44 hugger staff 1496 Mar 17 21:13 hugger
I know that the first line it the permissions, although I don't know what the order is. It would be great if that could be explained too. Then whats the number after it?
Basically, what do each one of these things mean? Why are the usernames written twice sometimes and don't match other times?
The option '-l' tells the command to use a long list format. It gives back several columns wich correspond to:
Permissions
Number of hardlinks
File owner
File group
File size
Modification time
Filename
The first letter in the permissions column show the file's type. A 'd' means a directory and a '-' means a normal file (there are other characters, but those are the basic ones).
The next nine characters are divided into 3 groups, each one a permission. Each letter in a group correspond to the read, write and execute permission, and each group correspond to the owner of the file, the group of the file and then for everyone else.
[ File type ][ Owner permissions ][ Group permissions ][ Everyone permissions ]
The characters can be one of four options:
r = read permission
w = write permission
x = execute permission
- = no permission
Finally, the "+" at the end means some extended permissions.
If you type the command
$ man ls
You’ll get the documentation for ls, which says in part:
The Long Format
If the -l option is given, the following information is displayed for
each file: file mode, number of links, owner name, group name, number of
bytes in the file, abbreviated month, day-of-month file was last modified, hour file last modified, minute file last modified, and the pathname. In addition, for each directory whose contents are displayed, the
total number of 512-byte blocks used by the files in the directory is
displayed on a line by itself, immediately before the information for the
files in the directory. If the file or directory has extended
attributes, the permissions field printed by the -l option is followed by
a '#' character. Otherwise, if the file or directory has extended security information (such as an access control list), the permissions field
printed by the -l option is followed by a '+' character.
…
The man command is short for “manual”, and the articles it shows are called “man pages”; try running man manpages to learn even more about them.
The following information is provided:
permissions
number of linked hardlinks
owner of the file
to which group this file belongs to
size
modification/creation date and time
file/directory name
I am trying to upload images or any other media type to my wordpress application, but I get this error:
Unable to create directory /home/admin/video/wp-content/uploads/2012/07. Is its parent directory writable by the server?
even though I am sure that the parent directory is writable. It actually has 777 permissions. What might be the problem?
Thank you.
The question is... writable by who or what? You probably need to make the entire "uploads" directory writable by PHP (a.k.a. the web server). Often, apache and other servers default to the user-group www-data, but it could be different. Check your apache or lighttpd (or whatever) configuration files to see what user and user-group it runs as. Often these are in /etc/apache or /etc/lighttpd et cetera. Then, make the uploads directory recursively writable to that group.
Using 777 permissions is a very bad idea. You always want to give the minimal amount of people access to any given directory. So, here's a short discourse on file permissions....
drwxrwxrwx 20 connermcd staff 680 Jul 25 20:38 img
-rw-r--r-- 1 admin www-data 18530 Jul 26 21:46 example
The first character of the permissions string denotes the type. In this case, img is a directory and example is a file. This could also be an l for a symbolic link (among other things). The remaining characters of the string (rwxrwxrwx) define permissions. As you can see, it's a repeating triplet of "read, write, execute". The first triad represents permission for the file or directory's owner. The owner is shown in the third column (connermcd for img and admin for example). The second triad denotes permission for the file or directory's group (staff for img and www-data for example). The last triad denotes permissions for anyone (even someone you gave temporary access to your server or a hacker, hint hint).
Each of the "read, write, execute" triads can be represented by a number. It's easy for me to think about rwxrwxrwx as 421421421. It's the only way multiples of two can add up to 7 if that helps you. So, the 4 stands for read, the 2 stands for write, and the 1 stands for execute. If you add these together then you can denote a triad with three numbers. So what chmod 777 img is really doing is giving "read, write, and execute" permission to everyone. It is also only setting those permissions for that directory and not the directories underneath it. To do this recursively you can use the -R flag -- chmod -R.
In your case, you just want to make the uploads folder and all its subdirectories available to the user group your server runs as. In most cases that's www-data, so I'll use that as an example. You probably want to set your project files as owned by your user to make them easier to move, edit, etc. So let's assume you are the owner of the files (use chown to set) and that they belong to the www-data group (use chgrp to set). In that case we want to give the owner full permissions and the group read and write permissions, and we want to do it recursively. So go to the parent directory of the uploads folder and do chmod -R 760 uploads.
You may also see if is correct your "Settings->Media" and then look to "Uploading Files" section.
The folder(and all subfolders) indicated into "Store uploads in this folder" must have 755 permissions.