[bug?] new admin user and file permissions

[winkiller]

just a quick paste from IRC, because I'm not sure about the first issue, I remember reporting something similar and it got fixed afaik.
The second also occurred to me, I think...

[21:19] (ShyK) is it intentional in beta3 that if you try to create an admin user you get "You cannot modify users with the same userlevel as yourself"?
[22:01] (ShyK) beta3 also has this issue...permissions are changed from my user to httpd on some files. like serendipity_config_local.inc.php and i can't do anything. because i'm on a shared hosting account, i don't own the server. this permission changing screws up everything for me.

[garvinhicking]

Serendipity creates file with Apache/PHP process ownership.

That means, your files will be owned by that process. Usually your FTP user account should be in the same group as Apache/PHP, so that you can still modify files.

If that is not the case, this is hard by Serendipity to detect. To give the file world-writable permissions would be a HUGE security issues.

You usually never need to make manual changes to the files, thus there is no real need why files should be more "unsecure" just to allow that.

The fix is pretty easy. Write a PHP script:

Code: Select all

<?php
chmod('serendipity_config_local.inc.php', 0777);
?>

Save it as "perm.php", call it via PHP, and then you can edit/delete/move the mentioned file as you like.

This is not a problem of Serendipity, but an issue with your host setup that cannot be enforced elseway because of imminent security issues.

Regards,
Garvin

[winkiller]

Well, I just tested it myself with 0.8.5.
When I do

Code: Select all

chown -R myuser codeschmie.de/
chgrp -R myuser codeschmie.de/

one at a time or both I get either a 403 forbidden or a simple "INCLUDE_ERROR"

Code: Select all

chown -R www-data codeschmie.de/
chgrp -R www-data codeschmie.de/

fixes it

/etc/group says:

Code: Select all

www-data:x:1234:myuser

[garvinhicking]

Of course it depends on your systems umask when the PHP file was/is created.

The PHP-Code snippet should work of course.

Regards,
Garvin

[Max Pain]

I've never had such an issue with any script. Not vBulletin, phpBB, MediaWiki and various other scripts. No one had the weird idea of changing server permissions, I don't know why Serendipity should be so different. I don't see how any security is compromised by having the files belong to my user. My account is in a FreeBSD "jail" that no one else can access, except server administrators. Taking away the rights from files makes no sense. I don't like to have no decent, accessible control over my files, on a server or anywhere else.

[garvinhicking]

Max Pain, please read what I wrote and the PHP script to change it. If Serendipity is more secure than phpBB and other systems, why would we change s9y to get more insecure? There are a lot of other systems around there which take similar approaches; Typo3 and coWiki come to my idea, and research would show up many others that restrict file access of config files to the webserver+group.

It's a all a matter of your user/group configuration.

Please don't take offense, but your postings tend to contain a bit aggression, which I think is uncalled for. We are only trying to make Serendipity more secure than other systems around, and your special server setup is an issue you need to deal with considering the circumstances.

[Don]

I also have a similar setup with a shared host. I'd kindly ask anyone if you could provide an accurate list of the files that are owned by httpd. I cannot update from beta 3 to 0.9 final and the list of files would help me greatly.

[garvinhicking]

The files that httpd needs write access to are:

.htaccess
serendipity_config_local.inc.php
templates_c/
templates_c/*
uploads/
uploads/*
archives/
archives/*

If you want to use Spartacus, also plugins/ needs to be writable.

HTH,
Garvin

[Don]

I ran this script:

Code: Select all

<?php
chmod('.htaccess', 0777);
chmod('serendipity_config_local.inc.php', 0777);
chmod('templates_c/', 0777);
chmod('templates_c/*', 0777);
chmod('uploads/', 0777);
chmod('uploads/*', 0777);
chmod('archives/', 0777);
chmod('archives/*', 0777);
?>

And now the script gives an error:

Code: Select all

Warning: chmod(): Operation not permitted in /hsphere/local/home/myname/myblog.mysite.com/perm.php on line 4

Warning: chmod(): No such file or directory in /hsphere/local/home/myname/myblog.mysite.com/perm.php on line 5

Warning: chmod(): Operation not permitted in /hsphere/local/home/myname/myblog.mysite.com/perm.php on line 6

Warning: chmod(): No such file or directory in /hsphere/local/home/myname/myblog.mysite.com/perm.php on line 7

Warning: chmod(): No such file or directory in /hsphere/local/home/myname/myblog.mysite.com/perm.php on line 9

[garvinhicking]

If that command is not allowed, go ask your provider about properly configuring PHP so that PHP scripts can be used on your host. With the current setting it's impossible for you to access files that are created from PHP applications, which makes no sense at all. It's a misconfiguration and improper "securing" of your provider.

Regards,
Garvin

[James]

Don,

Two things. First, leave the .htaccess file out of your script unless you find you really need it. I found that it can cause problems with the chmod() command. Something about the "." I think...

More importantly, you need to specify the full path for your files. Based on your error message, you would probably use:

chmod('/hsphere/local/home/myname/myblog.mysite.com/S9Y_INSTALL_DIR/serendipity_config_local.inc.php', 0777);


...where obviously you replace S9Y_INSTALL_DIR with the actual name of your installation directory.


One other thing. If you still get error messages after these changes, try commenting out some of your lines of code and CHMOD() just one file at a time...


Hope this helps!

James