Arch Linux

[dbdb]

[david@davidarch ~]$ ck-list-sessions
Session1:
unix-user = '1000'
realname = '(null)'
seat = 'Seat2'
session-type = ''
active = FALSE
x11-display = ':0'
x11-display-device = '/dev/tty7'
display-device = ''
remote-host-name = ''
is-local = FALSE
on-since = '2010-12-08T20:11:09.224856Z'
login-session-id = '4294967295'

[Hilinus]

Mmh, active dovrebbe essere a TRUE. Sicuro di aver sloggato e riloggato dopo la modifica? Per sicurezza prova anche a riavviare e poi, una volta loggato da terminale, ridai il comando una prima volta senza lanciare X, e poi un'altra quando sei dentro. Dovresti ottenere due sessioni distinte, una corrispondente al login su tty e una dopo aver lanciato il server grafico:

Codice: Seleziona tutto

[hilinus@archie ~]$ ck-list-sessions
Session9:
        unix-user = '1000'
        realname = ''
        seat = 'Seat1'
        session-type = ''
        active = TRUE
        x11-display = ':0'
        x11-display-device = '/dev/tty7'
        display-device = '/dev/tty1'
        remote-host-name = ''
        is-local = TRUE
        on-since = '2010-12-08T20:02:21.820416Z'
        login-session-id = '1'
Session4:
        unix-user = '1000'
        realname = ''
        seat = 'Seat1'
        session-type = ''
        active = FALSE
        x11-display = ''
        x11-display-device = ''
        display-device = '/dev/tty1'
        remote-host-name = ''
        is-local = TRUE
        on-since = '2010-12-08T19:09:35.340065Z'
        login-session-id = '1'
        idle-since-hint = '2010-12-08T20:02:50.015561Z'


[dbdb]

Codice: Seleziona tutto

[david@davidarch ~]$ ck-list-sessions
Session2:
    unix-user = '1000'
    realname = '(null)'
    seat = 'Seat1'
    session-type = ''
    active = FALSE
    x11-display = ''
    x11-display-device = ''
    display-device = '/dev/tty1'
    remote-host-name = ''
    is-local = TRUE
    on-since = '2010-12-08T20:39:27.957169Z'
    login-session-id = '1'
Session3:
    unix-user = '1000'
    realname = '(null)'
    seat = 'Seat1'
    session-type = ''
    active = TRUE
    x11-display = ':0'
    x11-display-device = '/dev/tty8'
    display-device = '/dev/tty1'
    remote-host-name = ''
    is-local = TRUE
    on-since = '2010-12-08T20:40:36.221973Z'
    login-session-id = '1'


Avevo già riavviato ma slogando e lanciando il commando da rl 3 ha funzionato,
poi mi ha sparato su tty8, ma non si può aver tutto.
Quindi tutto ok provo a riavviare per vedere che sia ancora tutto ok con il mio avvio su tty7

[dbdb]

Infatti come immaginavo
ravviato e la situazione è come prima quindi secondo me manca qualcosa in
.xinitrc , ma cosa? Nel senso che l'outpout postato deriva da uno startx da terminale
mentre in automatico la situazione rimane invariata.

EDIT il problema era dovuto a inittab con il login automatico che fino all'upgrade funzionava
ma adesso evidentemente no, ho risolto impostando inittab standard che richiede il login.
Quindi allo stato attuale con gli aggiornamenti probabilmente di ConsoleKit o di Polkit o polkit-gnome
il metodo riportato qui https://wiki.archlinux.org/index.php/Start_X_at_Boot_%28Italiano%29
potrebbe creare questo tipo di problema ed andrebbe rivisto!

EDIT2 ho commentato le opzioni in /etc/pam.d/login
e tutto è rimasto funzionante monto e spengo, ck-list-sessions mi da come attiva
quindi nel mio caso era totalmente relazionato a inittab!

[Berseker]

io sto usando testing, uso quel metodo dell'inittab da una vita e non ho mai avuto problemi.. uso xinit al posto di startx mettendoci il percorso completo nell'inittab (/usr/bin/xinit)

[veleno77]

sull' eeepc avvio in utomatico da initab,quindi senza login manager, uso kde e lo lancio

exec dbus-launch ck-launch-session startkde

[dbdb]

anch'io avvio in automatico da inittab, ma adesso devo scegliere utente e psw nel WM.
mi sembra di capire che voi ci riuscite ancora, quindi il problema è mio.
Berseker potresti postarmi inittab e xinitrc che usi?

EDIT @Berseker ho appena provato in questa maniera

x:5:once:/bin/su david -l -c "/bin/bash --login -c /usr/bin/xinit >/dev/null 2>&1"

si avvia corettamente ma il problema persiste!
Quindi sicuramente l'update ha modificato le policy in qualche forma.
Ciò vuol dire che se l'utente non si logga esplicitamente con usr name e psw
"perde" i privilegi evidentemente. Non tutti però in quanto rimango nel gruppo video ad esempio.
Quello che vorrei capire, è a quale livello e come devo agire sulle policy?? visto che groups
sembra by-passato o sovrascritto??

[veleno77]

questi sono i miei:
~/ cat .xinitrc

Codice: Seleziona tutto

#!/bin/sh
#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)
#
# exec ion
# exec jwm
# exec wmaker
exec dbus-launch ck-launch-session startkde
# exec icewm
# exec blackbox
# exec gnome-session
# exec startfluxbox
# exec startxfce4
# exec xfce4-session
# exec openbox
# exec dbus-launch ck-launch-session startlxde

~/ cat /etc/inittab

Codice: Seleziona tutto

#
# /etc/inittab
#

#  Runlevels:
#    0    Halt
#    1(S)       Single-user
#    2    Not used
#    3    Multi-user
#    4    Not used
#    5    X11
#    6    Reboot

## Only one of the following two lines can be uncommented!
# Boot to console
#id:3:initdefault:
# Boot to X11
id:5:initdefault:

rc::sysinit:/etc/rc.sysinit
rs:S1:wait:/etc/rc.single
rm:2345:wait:/etc/rc.multi
rh:06:wait:/etc/rc.shutdown
su:S:wait:/sbin/sulogin -p

# -8 options fixes umlauts problem on login
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux
c3:2345:respawn:/sbin/agetty -8 38400 tty3 linux
c4:2345:respawn:/sbin/agetty -8 38400 tty4 linux
c5:2345:respawn:/sbin/agetty -8 38400 tty5 linux
c6:2345:respawn:/sbin/agetty -8 38400 tty6 linux

# Hypervisor Virtual Console for Xen and KVM
#h0:2345:respawn:/sbin/agetty -8 38400 hvc0 linux

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

# Example lines for starting a login manager
#x:5:respawn:/usr/bin/xdm -nodaemon
#x:5:respawn:/usr/sbin/gdm -nodaemon
#x:5:respawn:/usr/bin/kdm -nodaemon
#x:5:respawn:/usr/bin/slim >& /dev/null 2>&1
x:5:once:/bin/su veleno77 -l -c "/bin/bash --login -c /usr/bin/startx >/dev/null 2>&1"

# End of file

[dbdb]

esattamente come i mie Veleno77, solo che sembro perdere i diritti dopo quest'update.
e se non effetuo il login esplicitamente non posso montare ne accedere a power,
che cosa regola queste policy?

[Hilinus]

Le policy sono regolate da policykit, mentre i dischi e il riavvio/spegnimento sono demandati a udisks e upower ( ovviamente ci sono le relative policy per questi due nella directory che ti ho scritto ieri ).

Ti posso dire che anche io avevo il problema che lamenti ed ho temporaneamente risolto editando le policy in questione dando i permessi a tutti gli utenti, in seguito definitivamente grazie alla modifica del file login in /etc/pam.d.

[dbdb]

Si ma deve essere qualcosa relativo alla policy
Utenza, o meglio tipo di login utente, in quanto, se l'utente accede specificando
Usr name e psw viene assegnato a tutti i gruppi di appartenenza, e il problema non sussiste,
Mentre utilizzando inittab per loggin senza inserire psw si presenta il ptoblema.
Quindi lo script di inittab postato sopra, per il login automatico,
Che cosa chiede di fare esattamente?, visto che la psw non é inserita!
Bisogna poter agire sulle policy che intervengono in quel processo credo.

[4javier]

su - run a shell with substitute user and group IDs

[dbdb]

david -l -c "/bin/bash --login -c

Ok per il su ma le opzioni e la parte relativa al login?

[4javier]

non fa altro che esguire una shell di login, che a sua volta avvia un'istanza di X.

[dbdb]

Ok, ma cosa rende possibile che l'acesso utenza avvenga senza l'inserimento
materiale della psw?
Qualcosa deve autorizzare il fatto che si possa accedere a tale utenza senza digitare la psw,
e quel qualcosa ne regola o ne fa ereditare anche le autorizazzioni credo

[veleno77]

penso che sia già in
/bin/su user

già li diventi il sistema passa all'utente scritto di conseguenza dovrebbe prenderne i privilegi...

[dbdb]

Appena arrivo a casa provo a guardarci, in effetti su passa all'utente,
é quel --login.....che non mi convice, in ogni modo dove sono definite le policy di su, e in quale pachetto è compreso?

[4javier]

quel parametro indica solo che la shell che verrà aperta deve essere una shell di login, cioè una shell che legge i vari file con le impostazioni personalizzate per l'utente selezionato.

[dbdb]

uhm, comunque questo è org.freedesktop.policykit.policy
a parte la traduzione in danese?!, potrebbe essere questo?
o sennò a monte cosa definisce un utente attivo?

Codice: Seleziona tutto

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>
  <vendor>The PolicyKit Project</vendor>
  <vendor_url>http://hal.freedesktop.org/docs/PolicyKit/</vendor_url>

  <action id="org.freedesktop.policykit.exec">
    <description>Run programs as another user</description>
    <description xml:lang="da">Kør et program som en anden bruger</description>
    <message>Authentication is required to run a program as another user</message>
    <message xml:lang="da">Autorisering er påkrævet for at afvikle et program som en anden bruger</message>
    <defaults>
      <allow_any>auth_admin</allow_any>
      <allow_inactive>auth_admin</allow_inactive>
      <allow_active>auth_admin</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.policykit.lockdown">
    <description>Configure lock down for an action</description>
    <message>Authentication is required to configure lock down policy</message>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>auth_admin</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/pklalockdown</annotate>
  </action>
</policyconfig>