Índice/Index

viernes, 29 de junio de 2012

Permisos Unix: Los bits SUID, SGID y sticky

Hola hoy escribiré sobre más permisos, esta vez será sobre los bits Sticky, SUID y SGID. Hablaré sobre ellos porque un seguidor solicitó que escribiera más sobre permisos, en particular estos.

Bit Sticky

El bit Sticky lo que hace es que al ejecutar una aplicación esta resida en memoria por lo que si otro usuario (pensando en sistema multiusuario) accede a esa misma aplicación se ejecutará más rápido ya que se encuentra activo en la memoria.
Entonces este permiso sirve para agilizar las ejecuciones en caso de que varios usuarios accedan a la vez a ella.

Bit SUID

Si aplicamos el bit SUID a una aplicación al correrlo se ejecutará con el UID del dueño del archivo aunque nosotros estemos logueados con un usuario distinto. Así que por ejemplo si necesitamos que todos los usuarios puedan utilizar fdisk sin tener que escalar a root o utilizar sudo sólo debemos aplicar este bit.

Bit SGID

Lo mismo que SUID pero aplica para el grupo al que pertenece la aplicación.


El bit SUID para ejecutar bash scripts como root

A pesar de que al aplicar SGID podemos ejecutar aplicaciones con un usuario diferente al que estamos logueados, hay cosas que de todas formas no podemos hacer aunque sea root el dueño del script.

Primero que todo para que un script se ejecute como root tendríamos que aplicar el bit SUID al shell que utilizamos para ejecutar los scripts ya que la aplicación en este caso es el shell, el script sólo es un archivo que será interpretado por el shell.

Comandos especiales como adduser no pueden ser ejecutados por cualquier otro usuario aunque tengan el SUID de root. Por lo tanto tampoco funcionaría un script que mande ejecutar adduser a pesar de que el shell sea SUID. Sino me creen pruebenlo ;) incluso le puse SUID root a mi shell, a adduser, a mi archivo .sh que mandaba ejecutar adduser y no lo permite.


El bit SUID y GTK+

GTK no soporta el uso de SUID o SGID. Por lo tanto si se intenta correr una aplicación basada en GTK con alguno de estos bits la ejecución mostrará una alerta y no iniciará.


¿Entonces en que se pueden usar estos bits?

Se puede utilizar para crear scripts que escriban archivos sobre directorios en los cuales otros usuarios no tienen permisos. Por ejemplo que cualquier usuario pueda mandar a crear un archivo a la carpeta personal de root.
O como mencioné anteriormente alguna aplicaciones si son posibles de usarse con SUID y SGID como fdisk.

Y tal vez ahora se preguntan bueno un script para mandar a escribir en /root, ¿Pero qué no habías dicho también que para que esto funcione se tiene que hacer que el shell sea el que tenga el bit SUID? Bueno hacer esto puede ser inseguro, el hacer que el shell siempre se ejecute como root quien quiera que sea el que lo utilice, pero hay un pequeño truco para que funcione sin hacer todo el shell root.

Sólo hay que copiar nuestro shell a otro directorio y ya en esa copia del shell aplicamos el SUID para que el shell original no sea siempre ejecutado por root. Ya después apuntamos nuestro sh hacia este shell.
De todas formas no es recomendable permitir tanto poder para correr scripts, pero si puede facilitar muchas cosas si el servidor o equipo donde se va a aplicar lo manejan solamente las personas encargadas o SysAdmin y manejan varias cuentas para acceder.


Los comandos para darle SUID a una copia del shell:

Primero encontremos donde está nuestro shell:





Lo que nos mostrará si estamos utilizando dash o bash, ahora a buscar su verdadera ubicación con la respuesta, utilicemos de ejemplo que nos apareció bash y busquemos como root o sudo para que no aparezcan errores de permiso denegado en la búsqueda:





Ya que lo tenemos lo copiamos a otro sitio en este ejemplo al home del usuario rukia desde /bin/bash:





Ahora aplicamos SUID o SGID a la copia de nuestro shell. 


Los comandos para aplicar estos bits son:

SUID:




Para quitar SUID:





SGID:




Para quitar SGID:




Para aplicar el bit sticky:





Para quitar el bit sticky:






Como se ven los permisos

Como se visualizarían los permisos para SUID si el dueño no tiene permisos para ejecutar la aplicación, en el ejemplo el dueño sólo tiene permisos de lectura y escritura, grupo lectura, otros lectura con SUID:




Visualización con SUID si el dueño si tiene permisos para ejecutar, en el ejemplo el dueño puede leer, escribir y ejecutar, grupo leer, otros leer con SUID:




Visualización con SGID si el grupo no tiene permisos para ejecutar, en el ejemplo el dueño puede leer, grupo leer y escribir, otros leer con SGID:





Visualización con SGID si el grupo tiene permisos para ejecutar, en el ejemplo el dueño puede leer, grupo leer, escribir y ejecutar, otros leer con SGID:





El bit sticky se visualiza de la siguiente forma si otros no tienen permisos de ejecución, en el ejemplo el dueño y grupo tiene todos los permisos, otros sólo de lectura y escritura con el bit sticky:





Y el bit sticky se visualiza de esta forma si otros si tienen permisos de ejecución, en el ejemplo el dueño, grupo y otros tienen todos los permisos con el bit sticky:




Bueno eso sería todo lo que se hasta ahora de estos bits, espero les sea útil, cualquier duda comenten. Saludos!

lunes, 25 de junio de 2012

How to install and configure suPHP

This tutorial is about how to install and configure suPHP. I know that they exist more tutorials about this but even though I'll write it because it took me a lot of time for me to make it work, and I want to explain how it finally work for me.
I made this installation and configuration with Fedora 16 and httpd.

What the suPHP module does is define which user and group will execute the PHP scripts. This is established inside one or more VirtualHost. This means that we can have multiple users for each one of our sites. They can even be executed by root but this is not advisable.

Now let's see how to install it:

It can be with yum or in case of Debian based distros with apt-get, but at least with Fedora and other similar distros I recommend to download the suPHP module from the official site. Here is the link:

Now that we have downloaded the package, we untar it:






We get inside the folder that is generated after de untaring and we configure the installation before compiling it:



What do the parameters mean:

--with-apxs=/usr/sbin/apxs: This establishes where is located apxs (this is where mine is located but it can be different in your distro, so first verify where it is yours). Apxs is an Apache utility that helps in the construction of modules.

--with-apr=/usr/bin/apr-1-config: This establishes where is located apr-1-config. Apr is the Apache Portable Runtime configuration utility.

--with-apache-user=apache: This establishes with what user is running actually Apache or httpd. (I wrote Apache, but you may have another user running your service, so first verify it).

--with-logfile=/var/log/httpd/suphp: This establishes where the logs for suPHP are going to be saved. It can be a different location as long as the user that runs Apache or httpd has writing permissions for that directory.

--with-setid-mode=paranoid: This establishes with what mode will be executed suPHP. Below you'll see the description of each mode.

--sysconfdir=/etc: This establishes the directory where suPHP will search for the configuration files. At least it most be readable by the Apache or httpd user.

--enable-SUPHP_USE_USERGROUP=yes: This enables the use of suPHP_UserGroup directive inside he Apache/httpd configuration. suPHP_UserGroup defines the user and group that will run the PHP scripts of Apache/httpd or just some VirtualHost.

Modes for executing suPHP:

Owner: The scripts will be executed with owner as the user and the owner group as the group.

Force: The scripts will be executed as the user and group established in the Apache/httpd configuration under the suPHP_UserGroup directive even if the owner and group of that script is other user and group. (suPHP doesn't recommend the use of this mode).

Paranoid: The scripts will be executed as the user and group established in the Apache/httpd configuration under the suPHP_UserGroup directive only if the user and group are the same as the owner and owner group of the script.

Now let's continue with the installation, now let's compile:






If any error appeared we proceed with installation:






Configuration of suPHP in Apache/httpd:

We have to edit or if it doesn't exist, create the file suphp.conf inside the directory established at the --sysconfdir parameter:




The next step in configuration:

For httpd on Fedora or similars:

Edit the file /etc/httpd/conf.d/suphp.conf with this:




And the configuration file for httpd in the VirtualHost section has to look like this (using as example the user rukia):




For Apache on Ubuntu or similars:

Add the first configuration text from above inside the VirtualHost that will use suPHP.

So the configuration for a VirtualHost in Apache on Ubuntu to run scripts as rukia will be:



And with this ends the installation and configuration of suPHP now we just have to restart the Apache/httpd service.

We can try our configuration for example with a script that creates a file inside our DOCROOT:

PHP code:



Any doubt please comment.

viernes, 22 de junio de 2012

Instalación y configuración de suPHP

Hola hoy voy a hacer este tutorial de como instalar y configurar el módulo suPHP para Apache o httpd.
La instalación la realicé en Fedora 16 con httpd.
Tal vez ya muchos saben como instalarlo pero de todas formas lo escribiré ya que yo nunca antes lo había hecho y si me tomo tiempo para algo tan sencillo que es el lograr que funcionara.

Lo que el módulo suPHP hace en si es definir que usuario y grupo ejecutará los scripts de PHP. Esto se define dentro de uno o varios VirtualHost. Esto quiere decir que podemos tener distintos usuarios para cada uno de nuestros sitios. Incluso pueden ejecutarse bajo root aunque no es recomendable.

Ahora como se instala:

Se puede con yum o en caso de distros basadas en Debian con apt-get, pero al menos en el caso de Fedora y otras distros similares recomiendo que se descargue desde la página oficial (lo digo por experiencia -.-). Aquí está el link: http://www.suphp.org/Download.html

Entonces ya descargado descomprimimos el paquete con:


Entramos a la carpeta que se generó tras descomprimir el paquete y configuramos la intalación antes de compilar:



Que son los parámetros establecidos:

--with-apxs=/usr/sbin/apxs: Establecemos donde se encuentra apxs (esta es mi ubicación pero puede variar según las distros, así que primero verifiquen en donde se encuentra su apxs). Apxs es una utilidad de Apache que ayuda en la construcción de módulos.

--with-apr=/usr/bin/apr-1-config: Igual que la anterior establecemos donde se encuentra en este caso apr-1-config. Apr es la utilidad de configuración Apache Portable Runtime.

--with-apache-user=apache: Se establece con que usuario está corriendo Apache o httpd. (Yo escribí Apache porque así está corriendo mi httpd pero revisen cual es el suyo).

--with-logfile=/var/log/httpd/suphp: Aquí establecemos en donde se van a estar almacenando los logs que genere suPHP. Puede ser una ubicación distinta siempre y cuando el usuario bajo el cual corre Apache o httpd tenga permisos de escritura sobre ese directorio.

--with-setid-mode=paranoid: Se establece bajo que modo se ejecutará suPHP. Más abajo viene la descripción de los distintos modos.

--sysconfdir=/etc: El directorio en donde se buscarán los archivos de configuración de suPHP. Al menos debe ser legible para el usuario de Apache o httpd.

--enable-SUPHP_USE_USERGROUP=yes: Habilitar el uso de suPHP_UserGroup dentro de la configuración de Apache o httpd. suPHP_UserGroup es para establecer el usuario y grupo bajo el cual se ejecutará Apache/httpd o cierto/ciertos VirtualHost.

Modos para ejecutar suPHP:

Owner(dueño): Los scripts se ejecutarán con el usuario y grupo del dueño del archivo.

Force(forzado): Los scripts serán ejecutados con el usuario y grupo establecidos en la configuración de Apache/httpd bajo suPHP_UserGroup sin importar que el dueño del script sea otro usuario o grupo. (suPHP no recomienda utilizar este modo ya que es el más inseguro).

Paranoid(Paranoico): Los scripts serán ejecutados con el usuario y grupo establecidos en la configuración de Apache/httpd bajo suPHP_UserGroup pero sólo si ese usuario y grupo coinciden con el usuario y grupo del dueño del script.

Ahora continuemos con la instalación, ya que se configuró pasemos a compilar:


Si no apareció ningún error podemos pasar a la instalación:




Configuración de suPHP en Apache/httpd:

Editamos o sino existe creamos el archivo suphp.conf dentro de /etc (o el directorio que establecieron que almacenaría los archivos de configuración). El archivo debe contener lo siguiente:



El siguiente paso en configuración:

Para httpd en Fedora o similares:

Editar el archivo /etc/httpd/conf.d/suphp.conf con lo siguiente:



Y el archivo de configuración de httpd en la sección de los VirtualHost debe quedar parecido a esto (suponiendo que queremos correrlo con el usuario rukia):




Para Apache en Ubuntu o similares:

Agregar el texto anterior dentro de los VirtualHost que utilizaran suPHP.

Por lo tanto la configuración para un VirtualHost de Apache en Ubuntu utilizando para ejecutar scripts al usuario rukia sería:




Y con esto finaliza la instalación y configuración de suPHP ahora sólo queda reiniciar el servidor Apache/httpd.

Se puede probar por ejemplo con un script que mande a crear un archivo dentro del mismo directorio:

Código PHP:



Cualquier duda comenten porfavor, saludos!

jueves, 21 de junio de 2012

How to calculate permissions from umask

Umask (user mask) is a command that defines what default permissions will be established when a file is created by a determined process or user.

First the basis: permissions are represented like this in Unix systems: rwx-rwx-rwx.

Where r - Read
w - Write
x - Execute

And where the first group of rwx belongs to the owner, the second to the group and the third to other users.

Example: rwx-r-x-r-x

In this case the permissions are: the owner has rights to read, write and execute. The group to read and execute. Other users to read and execute.

So now lets see how to obtain the permissions from a umask:

Example: if our umask is of 022, the default permissions for directories will be: 755 (drwx-r-x-r-x) and for files 644 (rw-r---r--).

And how did we obtain this? Now lets see how.
Before making any calculation:

The initial permissions for directories are 777.
The initial permissions for files are 666.

In the next steps will see how this values are applied to obtain the default permissions that the umask will provide using the example of the 022 umask.

First, we make a binary NOT to the umask 022:

Lets start with the first 2 (other users):

NOT 010=101=5

The NOT to the next 2 will also result in a 5 (group).

For the 0 (Owner):

NOT 000=111=7

So the result is 755.

Now that we have the NOT umask will get the default permissions for directories.
We just need to apply an AND binary operation with the 755 that we got before with the initial permissions for directories (777):

Lets start with other users:

101(5) AND 111(7) = 101(5)

Group:

101(5) AND 111(7) = 101 (5)

Owner:

111(7) AND 111(7) = 111 (7)

So the default permissions for directories will be 755 (rwx-r-x-r-x).

And now lets do the same for the files. For files initial permissions are 666. So the AND will be with 755 and 666.

Other users:

101(5) AND 110(6) = 100(4)

Group:

101(5) AND 110(6) = 100(4)

Owner:

111(7) AND 110(6) = 110(6)

So the default permissions for the files will be 644 (rw--r---r--).

Summary: with a umask of 022 we obtain 755 permission for directories and 644 permission for files.

Hope this post helps, if you have any doubt or you think something is wrong just comment. Or also if you think another example is necessary.

miércoles, 20 de junio de 2012

How to build an IPv6 address

An IPv6 address is composed by 8 fields of 16 bits and is represented like this:

x:x:x:x:x:x:x:x

Where each x is an hexadecimal value. If, in one of the fields we have zeros at the left it is not necessary to write them, also if a field has only zeros its representation can be simplified.

For example:

1080:0:0:0:8:800:200C:417A

Simplified will be like this: 1080::8:800:200C:417A

0:0:0:0:0:0:0:1

Simplified: ::1

Addresses are formed like this:




Where:

Site prefix: Composed of 48 bits. Describes the public topology that the ISP asigns.

Subnet ID: Composed of 16 bits. Is assign by the user or the site administrator. The subnet ID describes the private topology, also denominated site topology.

Interface ID: Composed of 64 bits. Contains the interface ID, also denominated token. The interface ID is configurated automatically using the MAC address of the interface or manually with the EUI64 format.

To convert the MAC address using the EUI64 format we just have to use this simple formula. But first let's see the parts of a MAC address.

Example:

00:04:AC:66:7D:47

The first field of 8 bits, in this case: 00. Is the universal/local bit (seventh bit).
The second and third field of 8 bits, in this case: 04:AC are the company ID.
And the three remaining fields, in this case: 66:7D:47 are the ID established by the company.

EUI64 convertion formula:

02:[company ID]:FF:FE:[ID established by the company]

Then using the MAC address of the example, the EUI64 format would be:

02:04:AC:FF:FE:66:7D:47

And finally to use this format as the interface ID of the IPv6 address, two fields of 8 bits have to be grouped to make fields of 16 bits:

0204:ACFF:FE66:7D47

Simplified: 204:ACFF:FE66:7D47

Now that we have the interface ID we can make an IPv6 address (this example uses an IPv6 global address):

2002:A09:807::204:ACFF:FE66:7D47



Some types of IPv6 addresses:

Non-specified address (0:0:0:0:0:0:0:0): This address shall never be asign to a node. This address indicates the absence of an address.

Link-local address: A link-local address is asign automatically to an IPv6 interface when it is activated.

Site-local address: It's an established range of addresses that are similar to the IPv4 private addresses. These addresses are used preferentially inside a site or in a LAN.

Global address: It's also an established range of addresses that are similar to the IPv4 public addresses.





 

And that's all hope it helps :)

martes, 19 de junio de 2012

Run Apache with multiple users

You can run Apache as multiple users with this module: apache2-mpm-itk. This module as I understand it is for executing one of the Apache processes as the user established in VirtualHost. So we can have multiple VirtualHost with multiple users.

I have already used this module with Ubuntu and Apache2.

Ubuntu installation:

apt-get install apache2-mpm-itk

Then we just have to add this line inside a VirtualHost (or in all the VirtualHosts we want to run with a different user than the default for Apache):

<IfModule mpm_itk_module>
AssignUserId User Group
</IfModule>


And that's all. But obviously if we want the directory established to that VirtualHost to work, it must have the right permissions for that user and group whether to run scripts or to write a file.
Even it's possible to run Apache as root.

Basic Linux stuff: The passwd file

The passwd file is located at /etc, and in that file is where the username and other user data is stored when a new user is created or when it is modified.
A line that represents the data of a user is written like this:

rukia:x:1000:1000:Rukia:/home/rukia:/bin/bash


  1. rukia - Is the username.
  2. x - This means that the user has a password. Passwords are encrypted and saved in the shadow file.
  3. 1000 - The user ID also known as UID.
  4. 1000 - The group ID also known as GID.
  5. Rukia - This field is the complete name of the user but it also contains other data. For example, when in Ubuntu we create a new user, it asks for a lot of information like room number, telephone, etc., well all this info is saved in this field and it is known as the gecos field.
  6. /home/rukia - The home folder.
  7. /bin/bash - Is the shell that will be executed by the user when he or she logins at a terminal.

viernes, 15 de junio de 2012

Como calcular permisos de umask

Hola, hoy voy a escribir sobre como se calculan los permisos resultantes de umask (máscara de usuario). El umask es una orden que establece que permisos por defecto se van a establecer al crear un archivo por determinado proceso o usuario.

Primero lo básico: los permisos se ven de esta forma en los sistemas Unix: rwx-rwx-rwx.

Donde r - Lectura
w - Escritura
x - Ejecución

Y donde el primer grupo de rwx corresponde al dueño, el segundo al grupo y el tercero a otros usuarios.

Por ejemplo: rwx-r-x-r-x 

En este caso los permisos serían: el dueño tiene derecho a lectura, escritura y ejecución. El grupo a lectura y ejecución. Otros usuarios a lectura y ejecución.


Entonces para calcular los permisos resultantes según la umask sería así:

Por ejemplo si nuestra umask es 022, el permiso por defecto para directorios sería: 755 (drwx-r-x-r-x) y para archivos 644 (rw-r---r--).

Antes de hacer los cálculos:

Los permisos iniciales para directorios son 777
Los permisos iniciales para archivos son 666

En los siguientes pasos se verá como se aplican estos valores iniciales para obtener los permisos por defecto que nos proporciona la umask.

Primero se hace una operación NOT binaria a 022:

Empezemos por el primer 2 (otros usuarios):

NOT 010 = 101 = 5

El siguiente 2 también sería 5 el resultado (grupo).

Para el 0 (dueño):

NOT 000 = 111 = 7

Por lo tanto el resultado es 755

Ahora pasamos a obtener los permisos que tendrán por defecto los directorios con esta umask negada:

Sólo debemos aplicar un AND de 755 y los permisos iniciales para directorios (777):

Iniciemos con otros:

101 (5)
AND 
111 (7) 
                   101 (5) RESULTADO

Grupo:

101 (5)
AND
111 (7)
                    101 (5) RESULTADO

Dueño:

111 (7)
AND
111 (7)
                    111 (7) RESULTADO

Por lo tanto los permisos que se establecerán por defecto para los directorios serán 755 (rwx-r-x-r-x).

Ahora lo mismo pero para los archivos. Para ellos los permisos iniciales son de 666. Entonces el AND será entre 755 y 666.

Otros:

101 (5)
AND 
110 (6) 
                   100 (4) RESULTADO

Grupo:

101 (5)
AND
110 (6) 
                   100 (4) RESULTADO

Dueño:

111 (7)
AND
110 (6) 
                   110 (6) RESULTADO

Por lo tanto los permisos que se establecerán por defecto para los archivos serán de 644 (rw--r---r--).

En resumen con umask 022 obtenemos permisos 755 para directorios y 644 para archivos.

Y bueno eso es todo espero lo haya explicado bien, cualquier duda pueden comentar. Esto lo hice porque para el siguiente post hay que establecer umask para suPHP, para que así se pueda entender porque se le da el valor que se le da al campo umask en esa configuración. Saludos!


viernes, 8 de junio de 2012

Como formar una dirección IPv6

Hola, hoy voy a explicar la representación de las direcciones IPv6 en honor a su lanzamiento esta semana.

Una dirección IPv6 está compuesta por 8 campos de 16 bits y se representa de la siguiente manera:

x:x:x:x:x:x:x:x

Donde cada x es un valor hexadecimal. Si en uno de los campos hay ceros hacia la izquierda no es necesario escribirlos, también si un campo consta de sólo ceros se puede simplificar su escritura.

Por ejemplo:

1080:0:0:0:8:800:200C:417A

Simplificada sería: 1080::8:800:200C:417A

0:0:0:0:0:0:0:1

Simplificada: ::1


Las direcciones están conformadas de la siguiente forma:

Donde:

Prefijo de sitio: Compuesto de 48 bits. Describe la topología pública que el ISP suele asignar al sitio.

ID de subred: Compuesto de 16 bits. Es asignada por el usuario o el administrador del sitio. El ID de subred describe la topología privada, denominada también topología del sitio



ID de interfaz: Compuesto de 64 bits. Contiene el ID de interfaz, también denominado token. El ID de interfaz se configura automáticamente desde la dirección MAC de la interfaz o manualmente en formato EUI­64.


Para convertir la MAC utilizando el formato EUI64 sólo hay que usar la siguiente fórmula que es muy sencilla. Pero primero vamos a ver como está conformada una MAC.

Ejemplo para ver como se forma:

00:04:AC:66:7D:47

El primer grupo de 8 bits, en este caso: 00. Es donde se encuentra el bit universal/local (séptimo bit).
El segundo y tercer grupo de 8 bits, en este caso: 04:AC son el ID de la compañía.
Y los tres grupos restantes, en este caso: 66:7D:47 corresponden al ID establecido por el fabricante.


Fórmula conversión EUI64:

02:[id de la compañía]:FF:FE:[id establecido por el fabricante]

Entonces utilizando de ejemplo la MAC anterior, el formato EUI64 quedaría de la siguiente forma:

02:04:AC:FF:FE:66:7D:47

Y finalmente para utilizar este formato como el ID de interfaz de la dirección IPv6, se agrupan dos grupos de 8 bits para hacer los campos de 16 bits:

0204:ACFF:FE66:7D47

Simplificado: 204:ACFF:FE66:7D47

Ya con el ID de interfaz se puede formar una dirección IPv6. En este ejemplo se muestra una dirección global IPv6:

2002:A09:807::204:ACFF:FE66:7D47

Algunos tipos de direcciones IPv6:

Dirección sin especificar (0:0:0:0:0:0:0:0): Nunca deberá ser asignada a ningún nodo. Esta dirección indica la ausencia de una dirección.

Dirección local de enlace (link-local): Cuando una interfaz IPv6 es activada, se le asignara automáticamente una dirección local de sitio.

Dirección local de sitio (site-local): Es un rango de direcciones establecido que vendría siendo como las direcciones privadas IPv4. Estas direcciones se utilizan preferentemente dentro de un mismo sitio o LAN.

Dirección global: Es también un rango de direcciones establecido que vendrían siendo como las direcciones públicas IPv4.


Y bueno esto es todo lo básico que se sobre IPv6, si tienen más dudas pueden comentar ya que no soy experta en el tema pero si lo maneje por un tiempo ya que realicé un trabajo en IPv6 para mi titulación. Pero cualquier duda me dicen y sino puedo responderla busco la info.

viernes, 1 de junio de 2012

Ejecutar Apache con múltiples usuarios en Ubuntu

Bueno otra vez voy a escribir algo rápido que puede ser útil.

Esta vez necesitaba ejecutar Apache como root, pero es obvio que esto no es seguro, así que quería ejecutar sólo un VirtualHost bajo root.

Buscando en Internet di con un blog que explicaba sobre un módulo para

Apache llamado apache2-mpm-itk. Este módulo según entiendo es para ejecutar uno de los procesos de Apache como el usuario establecido en el VirtualHost. Por lo tanto podemos tener múltiples VirtualHost con múltiples usuarios.

Este módulo ya lo utilicé en Ubuntu con Apache2, lo que no he logrado desfortunadamente es que me funcione en Fedora16 con httpd. Pero sigo haciendo el intento todos los días si me es posible de ver la forma de correr httpd con distintos usuarios. Existen otras opciones como suPHP y suExec pero no les he dedicado el tiempo para checarlos. Pero bueno sigamos con lo del módulo itk.

Para instalarlo en Ubuntu 

apt-get install apache2-mpm-itk

Después sólo basta agregar lo siguiente dentro de uno de nuestros VirtualHost:

<IfModule mpm_itk_module>
AssignUserId Usuario Grupo
</IfModule>


Y ya es todo. Pero obviamente para que funcione el directorio indicado para ese VirtualHost debe tener los permisos adecuados para ese usuario y grupo, ya sea para ejecutar scripts o escribir un archivo.
Incluso se puede ejecutar como root.


Espero les sirva este dato porque a mi me ha ayudado mucho para mi proyecto sólo espero resolverlo para Fedora y lo escribiré también


Conocí este módulo gracias a la publicación en este blog: http://blog.andreaolivato.net/open-source/running-apache2-virtualhost-with-different-users.html
 

 Cualquier duda dejen comentarios.