cómo encontrar quién está sosteniendo el locking de un file en RCS

Supongamos que locking un file que está controlado por RCS

[root@host1:/etc/yp]# co -l group auto_home RCS/group,v --> group revision 1.6103 (locked) done RCS/auto_home,v --> auto_home revision 1.4003 (locked) done [root@host1:/etc/yp]# 

Veo los files con ", v" generados en el directory RCS

 [root@host1:/etc/yp/RCS]# ls -lrth | tail -3 -r--r--r-- 1 root other 16M Feb 20 12:20 passwd,v -r--r--r-- 1 root other 3.5M Feb 21 23:03 group,v -r--r--r-- 1 root other 4.1M Feb 21 23:03 auto_home,v [root@host1:/etc/yp/RCS]# 

¿Podemos determinar quién está sosteniendo el file de locking? Todos los administradores usan el inicio de session "raíz" para realizar los cambios (por sudo-s para convertirse en raíz)

Si alguien ya ha bloqueado, veo el siguiente post

 [root@campyp:/etc/yp]# co -l group RCS/group,v --> group revision 1.6103 (locked) writable group exists; remove it? [ny](n): ^C RCS: Interrupt RCS: Cleaning up. [root@campyp:/etc/yp]# 

¿Podemos verificar quién ha bloqueado el file?

En RCS, los lockings se almacenan en el encabezado del file-file. Aquí hay un encabezado de ejemplo para ilustrar:

 head 1.1; access thomas; symbols; locks thomas:1.1; strict; comment @# @; 1.1 date 2014.08.14.00.40.55; author thomas; state Exp; branches; next ; desc @@ 

El command rlog proporciona esa información de encabezado:

 $ rlog 2linux,v RCS file: 2linux,v Working file: 2linux head: 1.1 branch: locks: strict thomas: 1.1 access list: thomas symbolic names: keyword substitution: kv total revisions: 1; selected revisions: 1 description: ---------------------------- revision 1.1 locked by: thomas; date: 2014/08/14 00:40:55; author: thomas; state: Exp; RCS_BASE ============================================================================= 

De forma pnetworkingeterminada, el autor de un locking se determina mediante la comprobación de las variables de entorno LOGNAME y USER . Esos se establecen cuando sus usuarios sudo , por ejemplo, para "rootear". Pero el comportamiento puede ser anulado:

  • Cuando sudo , el $USER original se guarda en SUDO_USER . Se podría restablecer $LOGNAME y $USER desde $SUDO_USER , haciendo que los lockings correspondan a los usuarios reales.
  • RCS está documentado para admitir el funcionamiento de setuid con los files propiedad de root . Es posible que pueda usar eso, en lugar de hacer que los usuarios sudo .

Otras lecturas:

  • rlog (1)
  • rcsfile (5)
  • ci (1) (ver discusión de setuid )

No. Si todos sus usuarios son root , entonces el locking siempre pertenecerá a root .

Este es un arreglo dudoso en el mejor de todos modos. Haga que los usuarios comprometan ediciones como ellos mismos; no debería haber una razón sensata para hacer estas cosas como root en primer lugar.