I’m quite new to programming and I’m currently using C++. I’m writing a small program (https://bitbucket.org/Superpelican/clamshell_cli/) that needs to create a (hidden) config directory in the users home folder (named .clamshell). The program will for example store language packs that it downloads and a settings file in the ~/.clamshell directory.
So created a .clamshell dir with
int mkdir_return_value = mkdir(config_dir.c_str(), 0660);
where config_dir contains “/home/username/.clamshell”. the home directory is obtained by getenv(“HOME”)
However whenever I try to enter the .clamshell dir my program created dolphin complains with: “Could not enter folder /home/jurre/.clamshell.”. When I check the permissions of the folder it seems the permissions of the folder seem to be set to forbidden to view and modify for owner (my user account is the owner), the group (users) and others. While my program should set the permissions to read and write allowed by owner and group. The dolphin permissions tab clearly says I’m the owner.
I can manually set the permissions in Dolphin from “forbidden” to “can view & modify content” for “owner”, “group” and “others”, even without entering the root password! According to online permissions calculators, including: Unix Permissions by Project Fondue, 0660 should allow the owner and his group to read and write. However Dolphin’s advanced permission tab says something else: http://ubuntuone.com/47WHlNx8eqBL4uB9CFgEYa
On 04/14/2013 10:56 AM, Superpelican wrote:
> whenever I try to enter the .clamshell dir my program created
> dolphin complains with: "Could not enter folder
> /home/jurre/.clamshell.
a directory which cannot be executed cannot be entered…
To begin with, you shoul post the permission of that file with the ls statement and not with some screen shot of some GUI tool:
ls -ld /home/jurre/.clamshell
Then, you yourself created it with 0660 as permission bits. There is/are not x bits there. Read something about the meaning of the x bit permission on directories. Then you will understand that it should have been 0770.
On file creation, that mask (being it 0660, 0770, or whatever) has bits removed that are in the umask. This is how a user creates a barrier against all sorts of programs he happens to run to give to much allowances at file creation. You can see your umask as active at that time and place with
umask
I guess that the answer is someting like 057 (can be different at your’s). This means that all permission sfor others and write persmission for fellow group users are not set at file creation, even if the program (like your program) asks for it. And that is most probably while your group write bit is not set.
Recap:
. You need x bits a least for owner (and maybe you want them for group also) because it is a directory, but you did not ask for them.
. The w bit for group is not set because of your umask.
BTW this hasn’t much to do with C++ prgramming, but with understanding Unix/Linux file permissions.
First of all I wasn’t aware of the fact that permissions have different meanings on directories than on files.
I changed my program, it now uses the 0700 permissions and I can now open the .clamshell folder without any problems.
Dolphin also confirms that only the owner as rwx permissions. I read this about the difference between UNIX permissions on files and
directories: linux - Why do directories need the executable (X) permission to be opened? - Unix & Linux Stack Exchange
Searching on “unix directories x bit permissions” with Google was enough
I assuming that the ‘d’ means that it’s a directory and the 2 indicates that I have 2 user accounts? Apart from that I think I
understand what the output means: the first rwx means that the owner has read, write and x bit permissions, where as the first “—”
means that the user’s group is forbidden to read, write and x bit. The second “—” means the same but for “others”.
So if you would have a file on which only the owner has read, write and x bit permissions and the owner’s group (users) has read permissions ls -ld would output this?:
rwxrw---- , right?
On 04/14/2013 01:16 PM, Superpelican wrote:
>
> I assuming that the ‘d’ means that it’s a directory and the 2 indicates
> that I have 2 user accounts?
no need to assume…it is written exactly what it
means…somewhere… (can’t put my finger on it, this second.)
> So if you would have a file on which only the owner has read, write and
> x bit permissions and the owner’s group (users) has read permissions ls
> -ld would output this?:
> rwxrw---- , right?
to me it looks like group can read and write…
this would like like what your words describe “rwxr-----”
Only you used QUOTE tags around your computer text. Please use CODE tags next time (uuse the # button in the toolbar). And then do not go for storytelling like: “ls -ld ~/.clamshel” but simply copy/paste the command with the output like:
henk@boven:~> ls -ld .kde4
drwxr-xr-x 9 henk wij 4096 23 nov 2011 .kde4
henk@boven:~>
And also include the prompts as I did. That tells more facts and more trustworthy then your “story telling”.
And of course Dolphin (or every other GUI file manager) will show the facts that you see with an ls command. But weare not testing Dolphin’s abilities to show permissions, are we?
And yes, the d means directory. And here are also -, b, c, l and more.
And no, the 2 does not mean anything about user accounts. Why should it? It is something within your home directory. No connection with anything insiode other users home directories. It is the number of hard links this file entry has.
My assumption is that you know where to find the basic information about such age old system commands like ls:
man ls
info ls
From the last I cite:
-l' –format=long’
`–format=verbose’
In addition to the name of each file, print the file type, file
mode bits, number of hard links, owner name, group name, size, and
timestamp ( Formatting file timestamps), normally the
modification time. Print question marks for information that
cannot be determined.
BTW you have far more users defined on your system then the two you are mentioning. Do
Am 14.04.2013 14:14, schrieb dd:
> this would like like what your words describe “rwxr-----”
>
You forgot the x for the group (otherwise the group cannot enter the
directory)
rwxr-x—
–
PC: oS 12.3 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.10.0 | GTX 650 Ti
ThinkPad E320: oS 12.3 x86_64 | i3@2.30GHz | 8GB | KDE 4.10.2 | HD 3000
HannsBook: oS 12.3 x86_64 | SU4100@1.3GHz | 2GB | KDE 4.10.0 | GMA4500
And like the other two above say: On a **directory. **allways combine r with x. On a directory r without x on any of the user/group/others bits is not something you will like.
Martin Helm wrote:
> Am 14.04.2013 14:14, schrieb dd:
>> this would like like what your words describe “rwxr-----”
>>
> You forgot the x for the group (otherwise the group cannot enter the
> directory)
> rwxr-x—
Except the OP was talking about a file here, not a directory, so no the
x bit shouldn’t be set.
Am 15.04.2013 12:55, schrieb Dave Howorth:
> Except the OP was talking about a file here, not a directory, so no the
> x bit shouldn’t be set.
>
In what way is that not a directory? From the first post
So created a .clamshell dir with
Code:
int mkdir_return_value = mkdir(config_dir.c_str(), 0660);
where config_dir contains “/home/username/.clamshell”. the home
directory is obtained by getenv(“HOME”)
–
PC: oS 12.3 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.10.0 | GTX 650 Ti
ThinkPad E320: oS 12.3 x86_64 | i3@2.30GHz | 8GB | KDE 4.10.0 | HD 3000
HannsBook: oS 12.3 x86_64 | SU4100@1.3GHz | 2GB | KDE 4.10.0 | GMA4500
Martin Helm wrote:
> Am 15.04.2013 12:55, schrieb Dave Howorth:
>> Except the OP was talking about a file here, not a directory, so no the
>> x bit shouldn’t be set.
>>
> In what way is that not a directory? From the first post
>
> So created a .clamshell dir with
> Code:
> --------------------
> int mkdir_return_value = mkdir(config_dir.c_str(), 0660);
> --------------------
> where config_dir contains “/home/username/.clamshell”. the home
> directory is obtained by getenv(“HOME”)
>
>
Please read the OP’s actual question relevant to the answer you are
discussing:
So if you would have a file on which only the owner has read, write and
x bit permissions and the owner’s group (users) has read permissions ls
-ld would output this?:
rwxrw---- , right?
The whole thread was about directories just the last post at some point
contained suddenly the word file in the last paragraph, well a directory
is also a file - so what?
Edit: before it is misunderstood what the “so what” means: Only the original poster can clarify if that was suddenly about an ordinary file which is not a directory or was again about directories
–
PC: oS 12.3 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.10.0 | GTX 650 Ti
ThinkPad E320: oS 12.3 x86_64 | i3@2.30GHz | 8GB | KDE 4.10.0 | HD 3000
HannsBook: oS 12.3 x86_64 | SU4100@1.3GHz | 2GB | KDE 4.10.0 | GMA4500
So if you would have a file on which only the owner has read, write and x bit permissions and the owner’s group (users) has read permissions ls -ld would output this?:
rwxrw---- , right?
When we take this literaly and isolated from what was discussed in this thread before, the only correct and to the point answer would have been “Yes” IMHO.
But we have a history here. And most of us think that the OP not only is interested in having combinations like -wxr—w- translated into words like: write and execute for the owner, r for the group and write for the world, but also in some background about the usefullness and logic of such combinations. And this specific for the type of file this thread is about: directory (which is more or less confirmed by him mentioning the -d option).
