Re: (deb-cat) microcode per CPU =? privatiu

[Josep Lladonosa]

On 29 November 2017 at 19:55, Narcis Garcia  wrote:

> Com vaig esmentar un altre dia, assajo coses amb un «Intel Pentium MMX»
> (i586).
> M'he adonat que, tant el Live-CD "standard" de Debian 8 com en una
> instal·lació ja completada, l'arrencada manifesta:
>
> microcode: intel cpu family 0x5 not supported
>
> Sembla que això signifiqui que el nucli predeterminat ja ve amb això
> preinstal·lat:
> https://packages.debian.org/jessie/intel-microcode
> (ja he verificat que el paquet no hi estigui)
>

Sí. Em vaig trobar amb algunes versions de nucli (tant recents com
antigues) que ja inclouen en la seva compilació l'intel-microcode.

He trobat això:

http://metadata.ftp-master.debian.org/changelogs/non-free/i/intel-microcode/unstable_README.Debian

Al final del document diu "it cannot be a module anymore in recent Linux
kernels".
Imagino que hi ha hagut versions de nucli anteriors que també
l'incorporaven dins.

Salutacions,
Josep



>
> --
>
>
> __
> I'm using this express-made address because personal addresses aren't
> masked enough at this mail public archive. Public archive administrator
> should fix this against automated addresses collectors.
>
>


-- 
--
Salutacions...Josep
--

(deb-cat) microcode per CPU =? privatiu

[Narcis Garcia]

Com vaig esmentar un altre dia, assajo coses amb un «Intel Pentium MMX»
(i586).
M'he adonat que, tant el Live-CD "standard" de Debian 8 com en una
instal·lació ja completada, l'arrencada manifesta:

microcode: intel cpu family 0x5 not supported

Sembla que això signifiqui que el nucli predeterminat ja ve amb això
preinstal·lat:
https://packages.debian.org/jessie/intel-microcode
(ja he verificat que el paquet no hi estigui)

-- 


__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.

Re: (deb-cat) Sticky-enganxos pel propietari de directori

[Ernest Adrogué]

2017-11-29, 16:46 (+0100); Narcis Garcia escriu:
> Un altre cas d'ús és la carpeta de xarxa:
> 
> $ mkdir /srv/DocumentsCompartits
> $ chgrp users /srv/DocumentsCompartits
> $ chmod u=rwXg,g=rwXg,o= /srv/DocumentsCompartits
> $ usermod --append --groups users pepita
> $ usermod --append --groups users pepito
> 
> Com es fa per a què pepita crei documents a la carpeta compartida i
> garantir que pepito també hi tindrà permisos r/w?

Com ja han comentat abans, això es pot aconseguir fàcilment amb ACLs :

$ setfacl -m default:g:users:rw /srv/DocumentsCompartits

Re: (deb-cat) Sticky-enganxos pel propietari de directori

[Narcis Garcia]

Un altre cas d'ús és la carpeta de xarxa:

$ mkdir /srv/DocumentsCompartits
$ chgrp users /srv/DocumentsCompartits
$ chmod u=rwXg,g=rwXg,o= /srv/DocumentsCompartits
$ usermod --append --groups users pepita
$ usermod --append --groups users pepito

Com es fa per a què pepita crei documents a la carpeta compartida i
garantir que pepito també hi tindrà permisos r/w?
L'Umask no resol això perquè no té efecte per xarxa (sftp/ssh per exemple).
Actualment, la única cosa segura és que, quan pepita crei elements a la
carpeta, aquests pertanyaran al grup «users» per herència. Ja només
faltaria que heretessin permisos r/w/s.


__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 29/11/17 a les 13:38, Toni Mas i Soler ha escrit:
> O no entenc exactament el què proposes o no sóc capaç d'imaginar-me ara
> mateix un cas d'ús que em pogués suposar una millora.
> Només per donar-hi voltes. Podries aportar un cas d'ús o fos interessant
> aquest comportament.
> 
> Personalment, un canvi així, em suposaria un gran esforç per
> interioritzar-lo i aplicar-lo al meu sistema, a més de la por que sempre
> m'han fet els permisos +s.
> 
> Salutacions,
> 
> Toni Mas
> 
> El dia 26 de novembre de 2017 a les 11:27, Narcis Garcia
> > ha escrit:
> 
> No sé si aquesta falta de funcionalitat depèn del nucli (com Linux) o de
> les eines GNU.
> M'agradaria proposar on sigui escaient que, l'atribut +s pel propietari
> d'un directori tingui el següent efecte enganxós:
> Que el grup dels nous elements creats a dins hereti els permisos de
> grup.
> Això tant pot millorar l'accés a fitxers, tant a les memòries USB, com a
> carpetes compartides entre usuaris que tinguin diferent «umask».
> 
> Algú sap on seria el millor loc per fer aquesta proposta?
> 
> Gràcies.
> 
> 
> 
> 
> __
> I'm using this express-made address because personal addresses aren't
> masked enough at this mail public archive. Public archive administrator
> should fix this against automated addresses collectors.
> El 26/11/17 a les 10:54, Narcis Garcia ha escrit:
> >
> https://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories 
> 
> >
> > Ja veig que les respostes són:
> > No.
> > Si.
> >
> >
> >
> >
> >
> > __
> > I'm using this express-made address because personal addresses aren't
> > masked enough at this mail public archive. Public archive
> administrator
> > should fix this against automated addresses collectors.
> > El 26/11/17 a les 10:41, Narcis Garcia ha escrit:
> >> No té cap efecte sobre futurs continguts d'un directori aquesta
> instrucció?
> >> $ chmod u+s LaMevaCarpeta
> >>
> >> Si la resposta és «no»; Es tracta d'un disseny incomplet de GNU o
> Unix?
> >>
> >> Gràcies.
> >>
> >
> 
> 

Re: (deb-cat) Sticky-enganxos pel propietari de directori

[Narcis Garcia]

No busco garanties, sinó més possiblitats.
O és que els sistemews FAT i NTFS no tenen pegues?



__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 29/11/17 a les 12:53, Ernest Adrogué ha escrit:
> i no hi ha cap garantia que tota la
> resta de gids i uids coincideixen

Re: (deb-cat) Sticky-enganxos pel propietari de directori

[Toni Mas i Soler]

O no entenc exactament el què proposes o no sóc capaç d'imaginar-me ara
mateix un cas d'ús que em pogués suposar una millora.
Només per donar-hi voltes. Podries aportar un cas d'ús o fos interessant
aquest comportament.

Personalment, un canvi així, em suposaria un gran esforç per
interioritzar-lo i aplicar-lo al meu sistema, a més de la por que sempre
m'han fet els permisos +s.

Salutacions,

Toni Mas

El dia 26 de novembre de 2017 a les 11:27, Narcis Garcia <
debianli...@actiu.net> ha escrit:

> No sé si aquesta falta de funcionalitat depèn del nucli (com Linux) o de
> les eines GNU.
> M'agradaria proposar on sigui escaient que, l'atribut +s pel propietari
> d'un directori tingui el següent efecte enganxós:
> Que el grup dels nous elements creats a dins hereti els permisos de grup.
> Això tant pot millorar l'accés a fitxers, tant a les memòries USB, com a
> carpetes compartides entre usuaris que tinguin diferent «umask».
>
> Algú sap on seria el millor loc per fer aquesta proposta?
>
> Gràcies.
>
>
>
>
> __
> I'm using this express-made address because personal addresses aren't
> masked enough at this mail public archive. Public archive administrator
> should fix this against automated addresses collectors.
> El 26/11/17 a les 10:54, Narcis Garcia ha escrit:
> > https://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories
> >
> > Ja veig que les respostes són:
> > No.
> > Si.
> >
> >
> >
> >
> >
> > __
> > I'm using this express-made address because personal addresses aren't
> > masked enough at this mail public archive. Public archive administrator
> > should fix this against automated addresses collectors.
> > El 26/11/17 a les 10:41, Narcis Garcia ha escrit:
> >> No té cap efecte sobre futurs continguts d'un directori aquesta
> instrucció?
> >> $ chmod u+s LaMevaCarpeta
> >>
> >> Si la resposta és «no»; Es tracta d'un disseny incomplet de GNU o Unix?
> >>
> >> Gràcies.
> >>
> >
>
>

Re: (deb-cat) Sticky-enganxos pel propietari de directori

[Ernest Adrogué]

2017-11-29, 09:05 (+0100); Narcis Garcia escriu:
> Recomanar FAT (o NTFS) és reconèixer que els sistemes de fitxers de
> GNU/Linux, tal com estan, no serveixen per escenaris tant comuns com les
> memòries USB. Ho veig com abandonar-se al fracàs.
>
> Per esmentar una mancança amb FAT i NTFS: No es pot aplicar permís
> d'execució a CAP fitxer, i aleshores no es poden «compartir» programes
> (increïble tractant-se de la filosofia del programari lliure!).

No dic que els sistemes de fitxers Unix no serveixen, dic que els
controls d'accés d'aquests sistemes de fitxers depenen d'una base de
dades d'usuaris i grups centralitzada.  Si no tens una base de dades
centralitzada, llavors els controls d'accés no són efectius i no té
sentit utilitzar-los, per tant, en aquest escenari, és millor utilitzar
FAT pel simple motiu que és més portable.  Si no et preocupa la
portabilitat pots utilitzar Ext, evidentment, però no t'enganyis a tu
mateix pensant que Ext et permet establir controls d'accés.

> La majoria de distribucions GNU tenen el mateix GID (100), per exemple,
> pel grup «users». Això vol dir que, establint aquest com a grup a
> heretar (g+s) hi ha moltíssimes possibilitats que sigui interpretat de
> la mateixa manera a qualsevol altre ordinador.
> Encara no m'he trobat amb cap ordinador que les meves memòries USB no
> les llegeixi identificant gid=100=users (una altra cosa és que els
> administradors de sistemes tinguin totes la cura d'incloure els usuaris
> comuns a «users»).

Excepte l'uid i gid 0, la resta es poden assignar de forma arbitrària.
No hi ha cap garantia que 100 és el grup "users" ni que el grup "users"
s'utilitza pel mateix propòsit, i no hi ha cap garantia que tota la
resta de gids i uids coincideixen, i que els comptes corresponen a les
mateixes persones.  Per tant, no hi ha cap tipus de seguretat.  En
aquestes circumstàncies és millor directament ignorar els permisos i
permetre accés a tothom, enlloc de crear una falsa il·lusió de
seguretat.

Re: (deb-cat) Sticky-enganxos pel propietari de directori

[Narcis Garcia]

Recomanar FAT (o NTFS) és reconèixer que els sistemes de fitxers de
GNU/Linux, tal com estan, no serveixen per escenaris tant comuns com les
memòries USB. Ho veig com abandonar-se al fracàs.

Per esmentar una mancança amb FAT i NTFS: No es pot aplicar permís
d'execució a CAP fitxer, i aleshores no es poden «compartir» programes
(increïble tractant-se de la filosofia del programari lliure!).

La majoria de distribucions GNU tenen el mateix GID (100), per exemple,
pel grup «users». Això vol dir que, establint aquest com a grup a
heretar (g+s) hi ha moltíssimes possibilitats que sigui interpretat de
la mateixa manera a qualsevol altre ordinador.
Encara no m'he trobat amb cap ordinador que les meves memòries USB no
les llegeixi identificant gid=100=users (una altra cosa és que els
administradors de sistemes tinguin totes la cura d'incloure els usuaris
comuns a «users»).

Però és que no discuteixo el comportament actual d'aquest bit del grup
(g+s), sinó d'un que no s'està aplicant: u+s
Es tracta d'avançar abans de trobar la perfecció.



__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 28/11/17 a les 21:50, Ernest Adrogué ha escrit:
> 2017-11-28, 20:19 (+0100); Narcis Garcia escriu:
>> La meva proposta és per a què s'heretin només els permisos r,w,s
> 
> Ho trobo una mica rebuscat.  En el cas de memòries USB els ids d'usuari
> i grup no tenen sentit perquè la informació sobre usuaris i grups és
> independent del sistema de fitxers.  Si, per exemple, en un ordinador
> assignes un fitxer a l'usuari "xyz", a l'altre ordinador pot ser que
> t'aparegui un altre usuari com a propietari, o a vegades t'apareixerà un
> número que no correspon a cap usuari.  Llavors els permisos d'accés
> tampoc tenen sentit, perquè es refereixen a usuaris i grups que no tenen
> una identitat definida fora d'aquell ordinador.  En aquests casos és
> millor un sistema de fitxer tipus FAT i fer servir arxius tar si vols
> preservar les metadades fitxers.
> 

Re: (deb-cat) Sticky-enganxos pel propietari de directori

[Narcis Garcia]

Per cert, a través de la xarxa (per exemple com jo he provat amb SSHFS),
el «umask» del servidor no s'aplica, sinó que s'aplica el del client.
Això resulta problemàtic per una carpeta compartida quan diferents
clients hi creen subdirectoris i fitxers amb diferent màscara de
permisos: Es pot fer que heretin el grup (g+s) però no té utilitat si no
se n'hereten també els permisos r/w/s per tal que tots els clients
tinguin assegurada la lectura i escriptura.




__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 29/11/17 a les 08:52, Narcis Garcia ha escrit:
> El propi grup principal de l'usuari (->gid) també actua com a «grup per
> defecte», doncs si un directori està marcat amb g+s ja preval el grup
> del directori per a nous elements per sobre del grup que aplica l'usuari
> de forma predeterminada.
> Així doncs, el mateix comportament hauria de tenir u+s per davant de la
> màscara (umask).
> 
> 
> 
> 
> __
> I'm using this express-made address because personal addresses aren't
> masked enough at this mail public archive. Public archive administrator
> should fix this against automated addresses collectors.
> El 28/11/17 a les 20:56, Robert Marsellés ha escrit:
>>
>>
>> El 28/11/17 a les 20:19, Narcis Garcia ha escrit:
>>> La meva proposta és per a què s'heretin només els permisos r,w,s
>>>
>>>
>>
>> Per curiositat i per allò de pensar amb els pros i contres de les
>> propostes. D'aquesta forma que proposes deixaria de tenir sentit
>> mantenir a la vegada la màscara per defecte 0022 per usuari i per grups
>> ¿Correcte? ¿Quina de les 2 versions de donar permisos és/sembla més útil
>> a la majoria dels usuaris?
>>
>> robert
>>
>