Doas vs Sudo

433815 dedi:

Persist özelliği ile bunun ne alakası var? Ayrıca persist özelliği opendoasda zaten var, sadece OpenBSD'deki gibi kernel bazlı bir yöntem kullanmak yerine sudo gibi zaman bazlı bir yöntem kullanıyor. Eğer bu ile sorununuz varsa sudo da kullanmamalısınız bence, çünkü o da aynı yöntemi kullanıyor.

Genişletmek için tıkla...

Eğer çok yararlı bir şey ise kullanırım. Ben yeni duydum "doas"ı ve çok satırlı kodların da bugsuz olabileceğini belirttim.

Silinen üye dedi:

Eğer çok yararlı bir şey ise kullanırım. Ben yeni duydum "doas"ı ve çok satırlı kodların da bugsuz olabileceğini belirttim.

Genişletmek için tıkla...

17 yıldır sudo kullanıyorum ne performansinda bir sorun gordum ne bir guvenlik acigindan etkilendim.

Silinen üye dedi:

Eğer çok yararlı bir şey ise kullanırım. Ben yeni duydum "doas"ı ve çok satırlı kodların da bugsuz olabileceğini belirttim.

Genişletmek için tıkla...

Bir deneyin derim. Sudo kullanmak arasında fark olacağını sanmıyorum, özellikle yeni bir GNU/Linux kullanıcıysanız.

433815 dedi:

Bir deneyin derim. Sudo kullanmak arasında fark olacağını sanmıyorum, özellikle yeni bir GNU/Linux kullanıcıysanız.

Genişletmek için tıkla...

Denerim. Kolayca kullanılabilecek bir şeye benziyor zaten.

Bir senaryo uygulayalım, x grubununa dahil kullanıcılar y ve z komutlarını çalıştırdığında parola sorulmasın.

Bu senaryoda, doas için doas.conf dosyasını açıp aşağıdaki satırları eklemeniz gerekiyor.


Sudo için sudoers.d dizini altında oluşturacağınız herhangi bir dosyaya aşağıdaki satırı eklemeniz yeterli olacaktır.


Bu senaryoya göre, sudo için tek bir satır ile birden fazla komutu tanımlayabiliyorsunuz. Ana yapılandırma dosyasına dokunulmaması sistem yöneticisi veya bir paket bakımcısı açısından da farklı senaryolara çözüm üretebilir, kısaca bu bir avantaj. Doas için aynı işlemde birden fazla satır kullanılması ve paket ya da sistem yöneticisine kolaylık tanınmaması dezavantaj oluşturuyor. Ayrıca görüldüğü üzere sudo için hazırlanan yapılandırma daha basit ve anlaşılır. Tabii doas ek yapılandırma dosyalarına izin veriyor olabilir, ama bir kaynak göremedim ve hazırladığım harici yapılandırma dosyası da çalışmadı.

Bir yazılımın kaynak kodlarının uzun ya da kısa olması ile, olası açık ya da bug sayısı arasında doğrusal bir ilişki olacağın sanmıyorum. Bununla ilgili yapılmış bir çalışma da bulunduğunu bilmiyorum, büyük ihtimalle yoktur. Böyle bir doğrusal bağlantı kurmaya çalışmak, daha uzun bir yolda daha fazla asfalt yaması olacağını ummak kadar basitleştirilemez. Yazılım kodlarının bu kadar basit bir şekilde kıstaslanabileceğini ummak bana safdillilik gibi geliyor. Daha iyi bir yazılım geliştiricisinin yazdığı kodlarda herhangi bir açık ya da hata bulunmayabileceği gibi, daha az iyi bir yazılım geliştiricisinin yazdığı daha az kodda daha çok açık ya da hata bulunabilir. Bununla birlikte daha çok kullanılan bir uygulama, daha fazla gözönünde olduğu için hatalarının ya da açıklarının daha fazla tespit edilmesi de ayrı bir olasılık sayılabilir. Bu, hata ve açıklarının daha iyi giderileceği ya da giderildiği sonucunu da üretebilir. Çok kullanılmayan ve daha az gözönünde olan bir yazılım daha fazla açık ya da hata olasığı içerse bile, sebepten kaynaklı sonuç itibariyle bunların tespit edilmemesi olasılığının yüksek olduğu değerlendirilebilir. Bence sudo ve doas ile ilgili durum için, bu yaklaşım daha ihtimal görünüyor.

Doas'ı bu konuda gördüğümden beri kullanıp denedim, ama herhangi bir performans avantajına şahit olmadım. Bu kadar küçük bir uygulamanın, daha küçük bir alternatifinin olması bence çok ilgi uyandırıcı değil. Merak edenler kullanabilir, ama cidden büyütülecek bir durum yok.

OzgunP dedi:

Bir yazılımın kaynak kodlarının uzun ya da kısa olması ile, olası açık ya da bug sayısı arasında doğrusal bir ilişki olacağın sanmıyorum. Bununla ilgili yapılmış bir çalışma da bulunduğunu bilmiyorum, büyük ihtimalle yoktur. Böyle bir doğrusal bağlantı kurmaya çalışmak, daha uzun bir yolda daha fazla asfalt yaması olacağını ummak kadar basitleştirilemez.

Genişletmek için tıkla...

Karmaşıklık arttıkça içindeki hatalar da artar diye düşünüyorum. Teorik olarak her iki uygulamayı da benzer nitelikteki kişilerin yazdığını düşünürsek hata sayısı daha fazla kod içeren programda daha fazla olacaktır. Tabii ki bu durum sadece matematiksel olarak geçerli, programların kodlarını incelemedim ve incelesem de anlayacağımı pek sanmıyorum. Pratikte ise dediğiniz gibi daha çok kullanılan programın hataları kullanan kişiler tarafından daha çabuk fark edilip kapatılabilir.

Hareket noktası karmaşıklık ya da kod büyüklüğü ise, sudo da yakın zamanda 2 tane hata ya da açık çıktıysa, Linux çekirdeğinde 500 tane hata çıkmalı gibi reel bir sonuç ortaya konulabilmeli. Karmaşıklığın aynı işi yapan iki farklı uygulamaya indirgenmesi için bir sebep olamayacağına göre, bu tür ilişkiyi ortaya koyabilen bir örnek ya da çalışmalar yoksa, önermeler geçersiz demektir.

Çok basit bir usb sürücüsünün kodlarında bir çok hata ya da açık bulunabileceği gibi, çok karmaşık bir GPU sürücüsünün kodlarında bu kadar açık bulunmayabilir.

GDM, LightDM ve SDDM kodları ile ilgili ayrıntılara şuradan ulaşarak aşağıya iliştirdim. https://codetabs.com/count-loc

GDM


LightDM


SDDM


Aşağıda da bunlarla ilgili CVE kayıtları mevcut. Karmaşıklık ya da kod büyüklüğü ile açıklar arasında herhangi bir ilişki maalesef mevcut değil.

GDM3: 10 açık


LightDM: 3 açık


SDDM: 5 açık

433815 dedi:

Olmayacağı anlamına da gelmez. Daha fazla kod, o kod içerisinde bir hata çıkma ihtimalini de arttırır.


Persist özelliği ile bunun ne alakası var? Ayrıca persist özelliği opendoasda zaten var, sadece OpenBSD'deki gibi kernel bazlı bir yöntem kullanmak yerine sudo gibi zaman bazlı bir yöntem kullanıyor. Eğer bu ile sorununuz varsa sudo da kullanmamalısınız bence, çünkü o da aynı yöntemi kullanıyor.

O "gelişmiş" özellikleri kullanıcıların %90ı kullanmıyor ise o gelişmiş özelliklerin ne anlamı kaldı?

Kullandığınız komuta göre değişen bir etken olduğunu belirtmiştim.

Genişletmek için tıkla...

Persist açıp deneyeceğim.

OzgunP dedi:

Bir yazılımın kaynak kodlarının uzun ya da kısa olması ile, olası açık ya da bug sayısı arasında doğrusal bir ilişki olacağın sanmıyorum. Bununla ilgili yapılmış bir çalışma da bulunduğunu bilmiyorum, büyük ihtimalle yoktur.

Genişletmek için tıkla...

Aslinda var calismalar. Bunu daha once de yazmistim ama buraya mi yazdim baska konuya mi hatirlamiyorum.

Satir sayisinin fazla olmasi direkt olarak ne kadar karisik oldugu hakkinda fikir vermez.

Bazi dillerin verbosity'si fazladir, ayni isi yapmak icin daha cok kod yazariz. Bazi diller daha high level'dir ayni isi yapmak icin daha az kod yazariz.

Buna alternatif uretilen cozumlerden birisi Assembly - Binary ciktilarini karsilastirmaktir. Hangi dilde yazarsan yaz en sonunda makine diline donuseceginden bu ikisini karsilastirmak mantikli gibi gelse de yine cozum olmaz. Cunku bazi isleri yapmak icin uzun uzun kod yazman gerekse dahi bu isin kendisinin daha sofistike oldugunu gostermez. Ornegin basit bir UI kodu icin 300 satir harcarsiniz ama ozunde cok basittir.

Fast Inverse Sqrt fonksiyonu 20 satirdan kisadir ama ne oldugunu cozmek icin insanlar makaleler yayimladilar.


O yuzden bir yazilimin kaynak kodunun ne kadar sofistike oldugunu cozmenin en guvenilir metrigi Cyclomatic Complx. analizidir. Bu da kod satirlari, if-else branchleri dikkate alinarak hazirlanan metric. Iste bu metrikle defekt sayisi arasinda korelasyon var.

Ayni isi yapan ayni programlama diliyle yazilmis iki uygulamadan satir sayisi fazla olan daha hatalidir cikarimi yanlis. Daha fazla test yazilmis olabilir, daha fazla abstraction yapilmis olabilir. Bu cok basite indirgenmis bir yaklasim. Ayrica genelde daha cok kullanilan programlarda daha fazla defekt bulunur cunku daha fazla user testine maruz kalir.

Kod yazan bug yazar, bugsiz yazilim olmaz. O yuzden kod sayisi arttikca insanlarin supheyle yaklasmasini anliyorum ama ayni isi yapan 2 program direkt bu acidan kiyaslanamaz.

İnanılmaz. Bu kadar büyük bir tartışmaya döneceğini bilmezdim.
Bu arada bloat diyenlere artık Brodie Robertson da katıldı.