Discussion:
webb app import directory
glaskoncILLa
2010-06-27 18:43:55 UTC
Permalink
Hi,

whats the best way to solve permission/location issue of directory which
serves for uploading files for later usage with web application?

Application has authentication over htpasswd defined in installation
process, so is it ok to give full permission for everyone on that
directory which is placed in /usr/share/PACKAGE?
Or is it better to give standard permissions and put note about it in
DEBIAN.readme?

Or is there some other way..?

Nenad
--
To UNSUBSCRIBE, email to debian-webapps-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@electronicflux.com
Tanguy Ortolo
2010-06-27 19:05:30 UTC
Permalink
Post by glaskoncILLa
Application has authentication over htpasswd defined in installation
process, so is it ok to give full permission for everyone on that
directory which is placed in /usr/share/PACKAGE?
I think 777 permissions are not needed, and are really too much. Keep in
mind that the server where this package is installed may have Unix
account or normal users, and that allowing them to read a webapp's data,
or worse, to write to it, should only be the admin's choice.

I do not see why 777 would be needed, is not 700 www-data:root enough?

In addition, the prefix /usr is, as I understand it, to be used for
packages only, and neither the admin nor the users should ever directly
modify files in it. Variable data should go to somewhere under /var.
Post by glaskoncILLa
Or is it better to give standard permissions and put note about it in
DEBIAN.readme?
It is better that a 777, sure. But could you describe the exact needs
you have for your package? As you describe it, it seems it can use some
uploaded code files, like dokuwiki, which package I maintain, can use
plugins uploaded through its web interface. If it is the case, I can
describe the solution I chose, to respect the FHS and the policy as
possible.
--
Tanguy Ortolo
sean finney
2010-06-27 19:23:03 UTC
Permalink
Post by Tanguy Ortolo
I think 777 permissions are not needed, and are really too much. Keep in
mind that the server where this package is installed may have Unix
account or normal users, and that allowing them to read a webapp's data,
or worse, to write to it, should only be the admin's choice.
I do not see why 777 would be needed, is not 700 www-data:root enough?
In addition, the prefix /usr is, as I understand it, to be used for
packages only, and neither the admin nor the users should ever directly
modify files in it. Variable data should go to somewhere under /var.
ack on both of this. depending on the context, permissions like described
above and a subdirectory like /var/lib/<pkg>/uploads assuming you need the
data to hang around permanently and otherwise s,lib,cache,.


sean

--
Andrew McMillan
2010-06-28 00:17:22 UTC
Permalink
- its all about IP network/addresses management aplication, mostly perl
CGI's on Mysql with some HTML and CSS. Upload directory is for
spreadsheets for importing data in applications.
- is it /usr/share/PACKAGE the best place for CGI's? Also what about
permissions there, CGI's must be executabile and seems to me all other
apps in /usr/share are root:root so I have to give x for everybody else
and that surely doesnt look like good thing..
It's OK - they shouldn't be in anyone's path. You might want it to
be /usr/share/PACKAGE/cgi-bin if there are other non-cgi scripts
in /usr/share/PACKAGE for running from cron or suchlike.
- what about changes from original source? Upstream application isn't
FHS compatible and I have made several changes in original code to
change paths and to make application use dbconfig-common generated file
for database connection credentials, do I have to describe/make diff's
of those changes?
There is normally a diff which is the debian packaging. You can chunk
this down to smaller bits and use a patch system or VCS packaging
system. Questions about this stuff are probably better done on -mentors.
- also, there are few scripts which can be executed from
terminal/crontab for automatic syncing against DNS, OCS inventory tool
and SNMP based collecting addresses directly from devices, /usr/bin?
If you expect them to be run from the command-line then /usr/bin but if
they are to be run from /etc/cron.d/PACKAGE or something like that, then
they could be in /usr/share/PACKAGE instead.
Maybe its the best if I attach beta version of package so if any of you
guys have half hour free to check what thats all about and point me in
right direction with locations, I would really appreciate that and you
be surely get some extra points for your version of heaven because I'm
working pretty hard, packaging and perl are new to me...
There is a quite active and helpful group of perl packagers, so you
might also consider asking for help / review for people on debian-perl
mailing list.

Cheers,
Andrew McMillan.
--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Do nothing unless you must, and when you must act -- hesitate.
------------------------------------------------------------------------
Andrew McMillan
2010-06-27 22:20:40 UTC
Permalink
Post by glaskoncILLa
Hi,
whats the best way to solve permission/location issue of directory which
serves for uploading files for later usage with web application?
Application has authentication over htpasswd defined in installation
process, so is it ok to give full permission for everyone on that
directory which is placed in /usr/share/PACKAGE?
Or is it better to give standard permissions and put note about it in
DEBIAN.readme?
Or is there some other way..?
Hi Nenad,

Firstly, if the directory will grow in size it should be somewhere
under /var, rather than being in /usr. Imagine that people may desire
to install /usr on a readonly partition, for security or embedded
reasons.

If it is something that can happily be cleaned out and will be replaced,
then /var/cache is a good starting point, or if it is more precious than
that then you probably want to create /var/lib/PACKAGE for this content,
and perhaps if it is likely there will be other directories for this
application in the future you may want to make
it /var/lib/PACKAGE/uploads or something along those lines.

You should set permissions on the directory to be the sort of
permissions you see as minimum necessary for the application and
administration of it. I would tend to suggest something like mode 660,
owner root, group www-data. If subdirectories might also be created in
there then you may want to make that group sgid (mode 2660).

Regards,
Andrew McMillan.
--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
You will be given a post of trust and responsibility.
------------------------------------------------------------------------
Paul Wise
2010-06-28 01:59:30 UTC
Permalink
[CCing you since I'm not sure you're subscribed, sorry if you are]

The permissions and location of an upload directory will vary from
server to server, setup to setup and URL to URL. Please leave that up
to the server administrator and make it as secure as possible by
default. The main thing that you should ensure is that the web server
configuration for the URL of the upload directory does not open the
server up to arbitrary code execution attacks (via uploaded
PHP/CGI/etc files) or cross-site scripting attacks (via uploaded
HTML/XML/SVG documents). The usual way to do this is to provide a
setup script for the app or use the one provided by whatever framework
the app is using.
--
bye,
pabs

http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-webapps-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@mail.gmail.com
Loading...