[drupal-devel] [bug] files folder created with incorrect permissions
StefanoCosta
drupal-devel at drupal.org
Fri Jan 28 22:11:54 UTC 2005
Project: Drupal
Version: cvs
Component: file system
Category: bug reports
Priority: normal
Assigned to: Morbus Iff
Reported by: Anonymous
Updated by: StefanoCosta
Status: patch
well I know this doesn't fix the problem... but i created from ftp a
"/files2" directory and set it as files directory in admin >
settings... it _seems_ to work.
StefanoCosta
Previous comments:
------------------------------------------------------------------------
September 8, 2004 - 19:04 : Anonymous
Hi,-
> [rreading at tribal html]$ ls -l www/files
> total 12
> drwxr----- 2 nobody nobody 4096 Sep 8 12:22 pictures
> drwxrwxrwx 2 rreading users 4096 Sep 8 12:33 tmp
> drwxr----- 3 nobody nobody 4096 Sep 8 12:33 upload
the problem is very strange, and might even be a nasty drupal bug: As
of the CVS version we decided to let drupal generate the folders
itself, so that Joe User needs not to use ssh or ftp to make /configure
various folders.
So these were generated by PHP and thus have the wrong permission. The
user PHP is a differnet user in this case, and something that PHP
created is inacessible to us.
I am aware that this is sierverspecific, but its annoying enought for
me (and probably others) not to ignore.
Regards, Ber
------------------------------------------------------------------------
November 19, 2004 - 03:46 : dtan
Any update on this. . ?? I recently installed the 4.5 Head and the
problem still exists. Recommendations on how to actually change the
permission on the folder?
dtan
------------------------------------------------------------------------
November 28, 2004 - 16:53 : killes at www.drop.org
The apache user did create this directories. So it is natural that they
have the apache user "nobody" as owner. Drupal should be able to handle
this just file. Can we close this report?
------------------------------------------------------------------------
November 28, 2004 - 16:58 : Bèr Kessels
No, please do not close. Its a bug IMO.
Because a lot of (v)hosts do not put apache in the same group as the
FTP user. It will work, file uplaods etc will work for Drupal, but you,
as user, cannot access the files anymore by FTP.
But even worse, you cannot remove your drupal installation, without
intervention of root (or the server maintainer). I had two "empty"
domains with 30 MB of files taking up space for 3 months.
Another domain will not let me mirror (backup) anything because of
this.
------------------------------------------------------------------------
November 30, 2004 - 04:55 : svemir
If PHP/apache can create these folders, it should be able to remove them
as well. Perhaps an option somewhere to remove folders created by
Drupal? Maybe a button next to the place in administration where the
folder is specified. And also maybe the creation of the folders should
be optional in the first place...
------------------------------------------------------------------------
January 20, 2005 - 02:52 : Morbus Iff
This just bit me today too. Installed the banner.module, and ensured
that my files/ directory was 777, with the owner as gangrene:user.
Uploaded a new banner, and for various reasons, it didn't work. As I
started to investigate, I found that the files/banner directory, which
was "successfully" created (success determined by "I can access files
uploaded in that folder via a URL) was not visible to my FTP server (at
this point, proFTPd, though I've not yet tested on vsftpd).
One of ProFTPds feature is to hide folders that do not have the
executable bit set. The default permissions of Drupal is not to set
these, per file_check_directory in includes/file.inc. So, my newly
Drupal-created files/banners folder was given the permissions of (where
wwwrun and nogroup are the Apache user/group).
drwxrw---- 2 wwwrun nogroup 88 Jan 19 20:03 banners
Since there's no execute for everyone, and since the "gangrene" user is
not part of "nogroup", I was not able to see, access, or modify the
newly created folder. I had to manually issue chmod('files/banners',
0761) to even look at the blasted thing.
My recommendation is to change the file_check_directory chmod to 0771,
which should create drwxrwx--x permissions. The extra execute
permission on the "nogroup" is harmless, and allows ProFTPd to display
it (in this case to "nogroup", but also perhaps to the "users" group on
other systems), and the execute permission for everyone is absolutely
required for me to see it in under ProFTPD. These permissions are
giving any extra (or damaging) permissions to anyone, but merely
following the expectations of various FTP servers concerning "what a
directory is".
There's a similar bug related to uploaded files, but I've not yet found
the code for that one.
------------------------------------------------------------------------
January 20, 2005 - 02:55 : Morbus Iff
Grrrr... "these permissions are NOT giving any extra (or damaging)
permissions".
------------------------------------------------------------------------
January 20, 2005 - 03:12 : Morbus Iff
To revise my previous statement, it would be best to use perms 0765,
which adds "read" access to the "everyone" group. The correction is
simple: if we want to /see/ the folder in FTP, then we also want to see
/inside/ the folder via FTP. Again, I don't believe this change really
gives extra dangerous permissions to anyone, merely grants the same
permission to an authenticated FTP user (if a file upload can be seen
on the web by people who know its there, then the same access should be
applied to FTP users with the right knowledge [ie., un/pw]).
------------------------------------------------------------------------
January 20, 2005 - 03:29 : Morbus Iff
Alrighty, hunted down the file (not directory) related problem. Unlike
directories, which require us to enter a mode, file uploads are not
specified, thus they take on the default umask of the web server's user
(in my case, wwwgroup:nogroup, 640). This further causes problems with
FTP viewing because "everyone" has no permission (in my case, since I'm
a part of the "users" group, I can not view, modify, delete, mirror,
etc. files that have been uploaded through Drupal).
This has been tracked down to file_copy() (includes/file.inc) and the
following lines, which copy the uploaded file from the temp directory
($source) to the final destination ($dest).
if (!@copy($source, $dest)) {
drupal_set_message(t('File copy failed.'), 'error');
return 0;
}
My proposal is to add an explicit chmod after the copy, granting read
permission to "everyone", something to the effect of the following,
which will give read and write to the webserver process, read to the
webserver group, and read to everyone (ie., little old me, not of the
webserver group).
if (!@copy($source, $dest)) {
drupal_set_message(t('File copy failed.'), 'error');
return 0;
}
chmod($dest, 0644).
------------------------------------------------------------------------
January 20, 2005 - 03:40 : Morbus Iff
Attachment: http://drupal.org/files/issues/fileperm.patch (606 bytes)
Attached is a patch for Drupal 4.5.1 that implements these changes
(directory is set for 764, not 765 - the mode in my previous comment
was [another] error). Last time I contributed a patch, I created a bug
so please review extra carefully.
------------------------------------------------------------------------
January 20, 2005 - 17:27 : Morbus Iff
In chatting about this with #drupal, I'm thinking that something more
than just "sane defaults" needs to be enabled. The patch I just
submitted still has one "fatal" flaw: it doesn't allow write
permissions for the FTP user. This was ultimately deliberate (more
chance of accepting the patch with less dangerous permission, and the
assumption that a Drupal-controlled upload also offered a
Drupal-controlled deletion), but still isn't ideal.
Unfortunately, with SuEXEC servers and various configurations, there is
no SAFE default: on one hand you're giving 666 to everyone because you
have to (wwwrun:nogroup) and on the other, 666 is too much (if you're
running under SuEXEC, then gangrene:users/640 is right, and 666 is
wrong).
I think the only way this will be truly solved is with user
intervention, which means umask settings for file/directory in the
"Files" section of admin/setting. This is also the same solution that
Movable Type uses, which allows two special settings in its mt.cfg:
# When creating files and directories, Movable Type uses umask settings
to
# control the permissions set on the files. The default settings for
file
# creation (HTMLUmask, DBUmask, and UploadUmask) are 0111; for
directory
# creation (DirUmask), the default is 0000. You should not change
these
# settings unless you are running MT under cgiwrap or suexec, or some
other
# scenario where the MT application runs as you; in addition, you
should not
# change these settings unless you know what they mean, and what they
do.
#
# DBUmask 0022
# HTMLUmask 0022
# UploadUmask 0022
# DirUmask 0022
#
# In addition to controlling permissions via umask settings, you can
also
# use the HTMLPerms and UploadPerms settings to control the default
# permissions for files created by the system (either as output files
or
# uploaded files). The only real use of this is to turn on the
executable bit
# of files created by the system--for example, if MT is generating PHP
files
# that need to have the executable bit turned on, you could set
HTMLPerms
# to 0777. The default is 0666. You should not change these settings
unless
# you know what they mean, and what they do.
#
# HTMLPerms 0777
# UploadPerms 0777
For our needs, we'd really only need a DirectoryUmask and a FileUmask
option. Is this an amicable solution to anyone? If I get you a patch,
will this be implemented in Drupal 4.6?
------------------------------------------------------------------------
January 21, 2005 - 17:58 : Morbus Iff
After further reflection, I'm now leaning toward:
* leave the current Drupal permissions as they are (ignore my previous
patch).
* add GUI options to change the directory/file mode (per last
comment).
The GUI would be two sets of dropdown boxes, one for files and one for
directories. The automatically chosen option for Files would be
"read/write for Drupal only" (umask: 0640), with another option of
"read/write for everybody" (umask: 0666). The directory options would
be the same with the following umasks 0771 or 0777.
------------------------------------------------------------------------
January 21, 2005 - 18:26 : Morbus Iff
This is a list of known possibilities that the proposed patch/UI
addresses. In each case, the proposed solution above will, BY DEFAULT,
create directories as 771 and files as 640. These possibilities run
through a number of ownership possibilities, and any solutions in
regards to an FTP user.
Possibility #1 (traditional):
* Drupal runs as user wwwrun, group nogroup.
* FTP user IS NOT a member of group nogroup.
* FTP user WILL see a Drupal-created directory.
* FTP user WILL NOT be able to modify/view Drupal-created directory.
* FTP user WILL NOT be able to modify/view Drupal-created files.
* Solution: Toggle "read/write for everybody" for files/directories.
* Pro: 777/666 is the only way this problem could be solved for FTP
user.
Possibility #2 (suexec/suPHP).
* Drupal runs as user FTPuser, group users.
* FTP user IS a member of group users.
* FTP user WILL see a Drupal-created directory.
* FTP user WILL be able to modify/view Drupal-created directory.
* FTP user WILL be able to modify/view Drupal-created files.
* Solution: None necessary. New defaults are fine.
Possibility #3 (oddball configuration):
* Drupal runs as user wwwrun, group users.
* FTP user IS a member of group users.
* FTP user WILL see a Drupal-created directory.
* FTP user WILL be able to modify/view Drupal-created directories.
* FTP user WILL be able to view Drupal-created files.
* FTP user WILL NOT be able to modify/delete Drupal-created files.
* Solution: Toggle "read/write for everybody" for files/directories.
* Con: Gives "everybody" too many permissions.
* Pro: This is an oddball config I've never seen.
Possibility #4 (oddball configuration):
* Drupal runs as user FTPuser, group nogroup.
* FTP user IS NOT a member of group nogroup.
* FTP user WILL see a Drupal-created directory.
* FTP user WILL be able to modify/view Drupal-created directory.
* FTP user WILL be able to modify/view Drupal-created files.
* Solution: None necessary. New defaults are fine.
* Pro: This is an oddball config I've never seen.
------------------------------------------------------------------------
January 26, 2005 - 22:12 : arnabdotorg
Here's one way:
Define: MIN_FILE_PERMS, MID_FILE_PERMS, MIN_DIR_PERMS, MID_DIR_PERMS
(e.g. 640, 666, 711, 771)
In the "admin" page (where "files" is checked for writability)
1. Create a file
2. Set it to MIN_FILE_PERMS
3. Delete it
4. If 3 fails, Set it to MID_FILE_PERMS. If does not fail, Set variable
for DRUPAL_FILE_PERMS to MIN_FILE_PERMS
5. Delete it
6. if 5 fails, throw error that files are not writable/deletable.
7. If 5 does not fail, Set variable for DRUPAL_FILE_PERMS to
MID_FILE_PERMS
Do the same thing for directories.
Also, I wont mind 3x2 checkboxes for Directories and File perms for
more detailed control _in addition_ to the above algo (the above algo
can be the "validate" part of the 3x2.
------------------------------------------------------------------------
January 26, 2005 - 22:19 : arnabdotorg
lol, ignore this, it's useless. I'm attributing my sense of logic to it
being 3:00 am here.
------------------------------------------------------------------------
January 26, 2005 - 22:29 : Morbus Iff
Arnab and I talked about this on IRC, and his proposed solution sounded
great ("go, go comment on the Issue and I'll make the patch. yay!"), no
UI necessary, hoohah. Well, I dunno what crack I was smoking, but this
doesn't actually work. If Drupal is wwwrun:nobody, then 1) will create
wwwrun:nobody/640, 2) will be unnecessary, and 3) would succeed,
causing MIN to be set as the DEFAULT, and morbus:users would still be
out in the cold for FTP access.
So, uh, ignore comment #14. It doesn't work.
Back to comment #12. Thoughts?
--
View: http://drupal.org/node/10658
Edit: http://drupal.org/project/comments/add/10658
More information about the drupal-devel
mailing list