0

In a CGI script, I execute a system call to make a directory, namely mkdir $dir. The parent directory under which this new directory is being created has a permission of 755. It doesn't allow me to create the directory unless the permission is 777. I am the owner of this directory, why do I need to set the permission to 777? This is on Google Cloud Compute.

brian d foy
  • 129,424
  • 31
  • 207
  • 592
  • 1
    What user are you logged in as, vs which user is running the script? – Rawley Fowler May 16 '23 at 17:18
  • 2
    Do you mean Apache CGI? If yes, the Apache user should be the owner. That is typically `www-data` but that depends on the configuration. – John Hanley May 16 '23 at 17:41
  • When you say a system call, do you mean `system "mkdir $dir"` or the built-in `mkdir $dir`? – Schwern May 16 '23 at 20:38
  • I tried \`mkdir -p $dir\` and also `mkdir $dir, 755`. I am logged in as "info" but it seems that www-data is the one creating the directory. I issued the command "sudo usermod -a -G www-data info" but still doesn't work. Also I did this" "grep ^www-data /etc/group" which yielded this: "www-data:x:33:info" – Marcos Camargo May 16 '23 at 20:39
  • info@linux-web-server [cgi-bin]# grep www-data /etc/group www-data:x:33:info info:x:1001:www-data – Marcos Camargo May 16 '23 at 20:46
  • This is what I have in right now. Is is correct? ># groups info info : info adm dip www-data video plugdev google-sudoers -- ># groups www-data www-data : www-data – Marcos Camargo May 17 '23 at 04:10

1 Answers1

0

In order to create a file in a directory, you need permission to write to the directory.

With 755, only the owner of the directory can write the directory.

With 777, any user can write the the directory.

This tells us that the user as which the process executes isn't the same as the user that owns the directory.

If the user was the same, 700 would suffice.

If the user was different, but the group was the same, 770 would suffice.

ikegami
  • 367,544
  • 15
  • 269
  • 518
  • The process is "www-data" and the owner is "info". – Marcos Camargo May 16 '23 at 21:36
  • You mean the process is running as user `www-data`, and the dir is owned by user `info`? That is consistent with what I said. That means the third-last digit of the permission isn't relevant. You have to look at the second-last or last depending on whether the groups of the two are the same or not. – ikegami May 17 '23 at 11:54
  • I made some changes to the file `/etc/group` and I want to go back to what it was originally. Should the groups be like this? `info : info adm dip www-data video plugdev google-sudoers `, and `www-data : www-data`? Thanks! – Marcos Camargo May 17 '23 at 12:53
  • I'm not in any position to know what groups you want your users to have. – ikegami May 17 '23 at 13:02
  • Comments is not the place for new unrelated questions. – ikegami May 17 '23 at 13:51
  • The subdirectory created by the process is owned by `www-data`. How do I set the owner of this directory to be `info` when it is created by the process? I tried `chmod o+s $dir` as well as `chmod u+s $dir` with no effect. The group changes with `chmod g+s` . – Marcos Camargo May 17 '23 at 14:50
  • `chown` is used to change onwership – ikegami May 17 '23 at 15:03
  • This is what I have even after issuing the command `chown info .misc` in the script ---> `drwxr-sr-x 2 www-data info 4096 May 17 16:19 .misc` – Marcos Camargo May 17 '23 at 16:23
  • my $dir = "${home_dir}${modified_directory}/.misc"; #my $results = `chown info $dir`; #my $results = `sudo chown info $dir`; my $results = chown "info", "info", $dir; print ".misc $results\n"; None of these work to change the owner. – Marcos Camargo May 17 '23 at 16:59
  • Re "*This is what I have even after issuing the command ---> rwx... www-data ...*", Since the process is running as www-data, it has full access to that directory now. – ikegami May 17 '23 at 18:59
  • I'm not even bother going to try to read the next comment. If it's info pertinent to your existing question, edit the question. If it's a new question, it doesn't belong here. – ikegami May 17 '23 at 19:00