You are not logged in. Please login or register.
iRedMail → iRedMail Support → iRedAPD problems & ?s
==== Required information ====
iRedMail - 0.9.0
CentOS 6.x
MySQL
Apache
iRedAdmin-Pro
First ? is whether these permissions/ownership are accurate?
-rw-r--r-- 1 501 games 921 Dec 30 21:47 reject_null_sender.py
-rw------- 1 root root 565 Jan 21 22:00 reject_null_sender.pyc
----
Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.
Default permission is:
# chown -R iredapd:iredapd /opt/iRedAPD-1.6.0
# chmod -R 0555 /opt/iRedAPD-1.6.0
# chmod 0500 /opt/iRedAPD-1.6.0/settings.pysettings.py contains several SQL/LDAP account credentials, so it cannot be read by others.
Default permission is:
# chown -R iredapd:iredapd /opt/iRedAPD-1.6.0 # chmod -R 0555 /opt/iRedAPD-1.6.0 # chmod 0500 /opt/iRedAPD-1.6.0/settings.pysettings.py contains several SQL/LDAP account credentials, so it cannot be read by others.
Thank you. As I suspected but one more question about the settings.pyc. As I understand it, the settings.pyc is the settings.py file being executed/compiled by Python. When it runs and compiles the settings.py to settings.pyc, it reverts to being owned by root root. Is this a problem and/or should it be forced to iredapd:iredapd as well? If forcing ownership, would a modified settings.py file then compile correctly to settings.pyc? Sorry for ignorance but not sure how python is executing technically.
Thanks
It's executed/compiled before switching to iredapd daemon user, so it's ok.
You can try to remove all .pyc files annd try again.
It's executed/compiled before switching to iredapd daemon user, so it's ok.
You can try to remove all .pyc files annd try again.
That does not appear to be correct or something is possibe wrong with CentOS/install and Python execution.
-r-x------ 1 iredapd iredapd 1.4K Jan 21 22:00 settings.py
-r-xr-xr-x 1 iredapd iredapd 1.1K Jan 21 22:00 settings.pyc
-r-xr-xr-x 1 iredapd iredapd 1.5K Dec 30 21:47 settings.py.sample
# service postfix stop
Shutting down postfix: [ OK ]
# service iredapd stop
Stopping iredapd ...
# mv /opt/iredapd/settings.pyc /opt/iredapd/settings.pyc.ORIG
-r-x------ 1 iredapd iredapd 1.4K Jan 21 22:00 settings.py
-r-xr-xr-x 1 iredapd iredapd 1.1K Jan 21 22:00 settings.pyc.ORIG
-r-xr-xr-x 1 iredapd iredapd 1.5K Dec 30 21:47 settings.py.sample
# service iredapd start
Starting iredapd ...
# service postfix start
Starting postfix: [ OK ]
-r-x------ 1 iredapd iredapd 1.4K Jan 21 22:00 settings.py
-r-------- 1 root root 1.1K Jul 1 08:00 settings.pyc
-r-xr-xr-x 1 iredapd iredapd 1.1K Jan 21 22:00 settings.pyc.ORIG
-r-xr-xr-x 1 iredapd iredapd 1.5K Dec 30 21:47 settings.py.sample
Halted both postfix and iredapd.
Removed /opt/iredapd/settings.pyc
Confirmed gone.
Rebooted.
Appears to have compiled to root without user intervention on startup.
-r-x------ 1 iredapd iredapd 1.4K Jan 21 22:00 settings.py
-r-------- 1 root root 1.1K Jul 1 08:15 settings.pyc
So when does iredapd daemon start in CentOS 6?
Using existing system and new build to compare results since new system is not starting following build with Nginx & SOGo options selected.
Related Thread/Post: http://www.iredmail.org/forum/post40714.html
Technically, who owns /opt/iRedAPD-x.y.z doesn't matter at all, but it must be readable by iredapd user. And the most important thing is: /opt/iRedAPD-x.y.z/settings.py must be readable by iredapd user and iredapd user only, readable by root user is ok (because if you're root, you can always read all files).
All python modules are run/executed/compiled when starting iRedAPD service as root user, after it loads required Python modules/files, it switches to run as iredapd user -- if iredapd service is compromised, cracker gets only privileges as iredapd user, not root user.
Sorry for the ignorance but looking to keep secure... Two systems: 1 using iredapd 1.4.4. & new is 1.6.0.
It appears that both systems are running uwsgi as root user which is a bad idea as I understand it.
# ps aux | grep -i 'uwsgi'
root 23432 0.0 0.0 103244 896 pts/0 S+ 12:36 0:00 grep -i uwsgi
# ps uax | grep -i "uwsgi"
root 1949 0.0 0.0 108436 1820 ? S 06:59 0:00 /bin/sh /etc/rc3.d/S85uwsgi start
root 1955 0.0 0.0 108168 1376 ? S 06:59 0:00 /bin/bash -c ulimit -S -c 0 >/dev/null 2>&1 ; /usr/sbin/uwsgi --ini /etc/uwsgi.ini
root 1956 0.0 0.0 57024 3260 ? S 06:59 0:01 /usr/sbin/uwsgi --ini /etc/uwsgi.ini
root 1957 0.0 0.0 56572 1252 ? S 06:59 0:01 /usr/sbin/uwsgi --ini /etc/uwsgi.ini
2001 1958 0.0 0.0 163400 6244 ? S 06:59 0:01 /usr/sbin/uwsgi --ini iredadmin.ini
root 1959 0.0 0.0 57024 1008 ? S 06:59 0:00 /usr/sbin/uwsgi --ini /etc/uwsgi.ini
root 1960 0.0 0.0 57024 1008 ? S 06:59 0:00 /usr/sbin/uwsgi --ini /etc/uwsgi.ini
2001 1964 0.0 0.0 180528 4956 ? S 06:59 0:00 /usr/sbin/uwsgi --ini iredadmin.ini
root 2146 0.0 0.0 103244 880 pts/2 S+ 12:42 0:00 grep -i uwsgi
Isn't this a security concern/risk?
Plus, if I understand this: "after it loads required Python modules/files, it switches to run as iredapd user"
You're implying the daemon or script is going to change ownership back which is NOT occurring....
If my understanding is correct, should and/or can the scripts be modified to NOT Run uwsgi as root?
FYI: There is also a reference to uwsgi possibly being controlled by manage.py operating as root.
It appears that both systems are running uwsgi as root user which is a bad idea as I understand it.
The uwsgi main program is running as root, but uwsgi app 'iredadmin' (/etc/uwsgi.d/iredadmin.ini) is running as 'iredadmin' user. So this should be fine.
Plus, if I understand this: "after it loads required Python modules/files, it switches to run as iredapd user"
You're implying the daemon or script is going to change ownership back which is NOT occurring....
i don't quite understand your explanation. Why you expect "change ownership back"?
Running as root first, then switching to a low-privilege user is quite normal, including Dovecot. After switching user, the service is running as a low privilege user, this is fine.
If my understanding is correct, should and/or can the scripts be modified to NOT Run uwsgi as root?
FYI: There is also a reference to uwsgi possibly being controlled by manage.py operating as root.
uwsgi main program doesn't serve any program, so it's ok. You see below processes?
2001 1958 0.0 0.0 163400 6244 ? S 06:59 0:01 /usr/sbin/uwsgi --ini iredadmin.ini
2001 1964 0.0 0.0 180528 4956 ? S 06:59 0:00 /usr/sbin/uwsgi --ini iredadmin.ini
pbf343 wrote:It appears that both systems are running uwsgi as root user which is a bad idea as I understand it.
The uwsgi main program is running as root, but uwsgi app 'iredadmin' (/etc/uwsgi.d/iredadmin.ini) is running as 'iredadmin' user. So this should be fine.
Plus, if I understand this: "after it loads required Python modules/files, it switches to run as iredapd user" You're implying the daemon or script is going to change ownership back which is NOT occurring....
i don't quite understand your explanation. Why you expect "change ownership back"?
Running as root first, then switching to a low-privilege user is quite normal, including Dovecot. After switching user, the service is running as a low privilege user, this is fine.
I was looking for clarification from your previous comment: "after it loads required Python modules/files, it switches to run as iredapd user." So while you say the process is started as root, it (the process) switches to iredadmin ownership but the actual file does not change ownership.
If my understanding is correct, should and/or can the scripts be modified to NOT Run uwsgi as root?
FYI: There is also a reference to uwsgi possibly being controlled by manage.py operating as root.
uwsgi main program doesn't serve any program, so it's ok. You see below processes?
Maybe I do not understand admin process control well enough; however, as i understand it....
uwsgi being launched or operated as root user is a bad idea. In the event one can break out of the uwsgi process controlled by ireadmin, they would then have Python use as root user.
Maybe you can explain what is the logic for NOT putting it into user space vs root account or why an application should be operated as such scenario?
On another note, is the daemon a good candidate for "virtual environment" type application where you're not using the system Python but whatever you desire?
Thanks for the info as am trying to determine why it is NOT starting (possibly missing log file: http://www.iredmail.org/forum/post40742.html ) along with making sure it is secure.
Below is CROSS REFERENCE TO THIS POST regarding auto starting:
http://www.iredmail.org/forum/post40820.html
Information for everyone to see.
daemonize active in uwsgi.ini file
mkdir /var/log/uwsgi/
touch /var/log/uwsgi/uwsgi.log
chmod 0640 /var/log/uwsgi/uwsgi.log
REBOOT of the system.
service iredapd status
iredapd is running.
tail /var/log/uwsgi/uwsgi.log
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 145536 bytes (142 KB) for 1 cores
*** Operational MODE: single process ***
*** no app loaded. going in full dynamic mode ***
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 1980)
Sat Jul 4 08:39:01 2015 - [emperor] vassal iredadmin.ini has been spawned
spawned uWSGI worker 1 (pid: 1990, cores: 1)
Sat Jul 4 08:39:01 2015 - [emperor] vassal iredadmin.ini is ready to accept requests
NOTE:
Left the uwsgi log dir and file owned by root at present.
TO ANSWER:
Should uwsgi dir or uwsgi.log be owned by ireadmin, or in future plans of such?
Are the permissions below accurate?
drwxr-xr-x 2 root root 22 Jul 4 08:21 uwsgi
-rw-r----- 1 root root 3.7K Jul 4 08:39 uwsgi.log
TO ANSWER:
Should uwsgi dir or uwsgi.log be owned by ireadmin, or in future plans of such?
Are the permissions below accurate?
drwxr-xr-x 2 root root 22 Jul 4 08:21 uwsgi
-rw-r----- 1 root root 3.7K Jul 4 08:39 uwsgi.log
owned by root.
I was looking for clarification from your previous comment: "after it loads required Python modules/files, it switches to run as iredapd user." So while you say the process is started as root, it (the process) switches to iredadmin ownership but the actual file does not change ownership.
You're right. I will update iRedAPD document to make it clearer.
Maybe you can explain what is the logic for NOT putting it into user space vs root account or why an application should be operated as such scenario?
uwsgi is an application container, currently we run only iRedAdmin under uwsgi (as 'iredadmin' user), but you can run more/other applications (as different users) too.
If you run uwsgi as non-root user, it cannot switch to other users, and you have to run all applications as SAME user defined in /etc/uwsgi.ini.
iRedMail → iRedMail Support → iRedAPD problems & ?s
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 2 official extensions. Copyright © 2003–2010 PunBB.
Generated in 0.009 seconds (74% PHP - 26% DB) with 8 queries