December 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] about vm dropping privileges

by Michael Roberts

reading about how unix programs drop privs it seems they can use seteuid() to alter the state of the calling process. Not that the VM needs to be 'fixed' but could the application be enhanced, using OSProcess perhaps?, to drop privs in this way once port 80 has been bound to? I read somewhere else that some applications spawn child processes with modified privs. i don't know much about the details, just interested. Mike On Tue, Dec 2, 2008 at 9:30 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> my question was more how can the VM be fixed :) > > That's not a VM issue. It's not even a Smalltalk issue. ...

Dec. 2, 2008

Re: [Pharo-project] about vm dropping privileges

by Alexandre Bergel

> > Unix blocks port 1 - 1024 for non root users. Running a Smalltalk > image as root is obviously a very bad idea, especially when used for > web services. Smalltalk is full of security holes (for example Object > class>>#readFrom: uses the compiler) that would allow a smart person > to gain root rights. It is always good idea to run anything that is > publicly reachable in some sort of a sandbox, even if this is just by > using a non-privileged user. Hi Lukas, I read the thread you mentioned. Isn't it feasible to make the port 80 accessible for a non-root process? This is probably hardcoded in the kernel, but since this problem has been around for years in most communities, but not to fix this in the kernel? Just a very naive question :-) Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 2, 2008

Re: [Pharo-project] about vm dropping privileges

by Lukas Renggli

> my question was more how can the VM be fixed :) That's not a VM issue. It's not even a Smalltalk issue. It is just common sense to not run anything reachable in public as root. There is nothing to be fixed. As a developer you usually want to be able to freely interact with the rest of the world (FFI, Aliens, OSProcess, etc), but keep the risk of a system break-in as low as possible. Also see the recent discussion in the Squeak mailing-list about that: <http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-November/132679…>. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 2, 2008

Re: [Pharo-project] about vm dropping privileges

by StÃ©phane Ducasse

my question was more how can the VM be fixed :) Stef On Dec 2, 2008, at 10:00 PM, Lukas Renggli wrote: >> I was rereading our excellent forthcoming seaside book :) > > *lol* > >> And lukas wrote >> >> "To listen on port 80, the standard port used by the HTTP >> protocol, >> the >> web server needs to run as root. Running a public service as >> root is >> a huge security issue. Dedicated web servers such as Apache >> drop >> their root privileges after startup. This allows them to >> listen to >> port >> 80 while not being root. Unfortunately this is not something >> that can >> be easily done from within the Smalltalk VM. " >> >> And I was wondering what is the exact problem? > > Unix blocks port 1 - 1024 for non root users. Running a Smalltalk > image as root is obviously a very bad idea, especially when used for > web services. Smalltalk is full of security holes (for example Object > class>>#readFrom: uses the compiler) that would allow a smart person > to gain root rights. It is always good idea to run anything that is > publicly reachable in some sort of a sandbox, even if this is just by > using a non-privileged user. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 2, 2008

Re: [Pharo-project] Removing a trait from a class

by StÃ©phane Ducasse

I was using the package browser Stef On Dec 2, 2008, at 10:11 PM, Adrian Lienhard wrote: > ok, we need to take a closer look at this, > Do you remember which browser you used? If Omnibrowser, do you also > know which one? > Adrian > > On Dec 2, 2008, at 13:58 , StÃ©phane Ducasse wrote: > >> Adrian >> I got some problems during the last smalltalk party at paris. >> my pair programmer quitted the image without saving and when I >> reloaded the changes it was a mess. >> I could not remove methods from a class. The methods were not in >> the method dictionary but their names showed >> up in the browser.... The class organizer had them in. I would love >> to check the classorganizer concept :) >> I could not remove the traits from the class. >> >> Stef >> >> On Dec 2, 2008, at 11:26 AM, Adrian Lienhard wrote: >> >>> Hi Hilaire, >>> >>> Which UI tools do you use? Omnibrowser or the old browser that is >>> shipped with the Core image. >>> Could you try to reproduce the problem in a newer version of >>> Pharo? (10050 is *very* old). >>> >>> I'd like to take a look then. It's strange because we have been >>> using traits for two years now without seeing this problem. So it >>> may indeed be a problem related to the UI that somehow brings >>> traits into an inconsistent state. >>> >>> Adrian >>> >>> >>> On Dec 2, 2008, at 11:08 , Hilaire Fernandes wrote: >>> >>>> I can't remove a trait from a class using UI tools. (pharo 10050) >>>> How can I remove it programmatically ? >>>> >>>> Next with this same class, message from this trait are not >>>> reachable, >>>> the MNU is raised but the hierarchy is not right as IFIETayage1 >>>> is not >>>> a subclass of IFIExoMorph. However IFIExoMorph is using the same >>>> trait >>>> as IFIEtayage. >>>> It looks like there is mismatch in the classes with traits. (see >>>> screenshot) >>>> >>>> Now I realize my last istoa release suffer from this problem :) >>>> >>>> Hilaire >>>> >>>> -- >>>> http://blog.ofset.org/hilaire >>>> <bug-trait.png>_______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 2, 2008

Re: [Pharo-project] Removing a trait from a class

by Adrian Lienhard

ok, we need to take a closer look at this, Do you remember which browser you used? If Omnibrowser, do you also know which one? Adrian On Dec 2, 2008, at 13:58 , StÃ©phane Ducasse wrote: > Adrian > I got some problems during the last smalltalk party at paris. > my pair programmer quitted the image without saving and when I > reloaded the changes it was a mess. > I could not remove methods from a class. The methods were not in the > method dictionary but their names showed > up in the browser.... The class organizer had them in. I would love > to check the classorganizer concept :) > I could not remove the traits from the class. > > Stef > > On Dec 2, 2008, at 11:26 AM, Adrian Lienhard wrote: > >> Hi Hilaire, >> >> Which UI tools do you use? Omnibrowser or the old browser that is >> shipped with the Core image. >> Could you try to reproduce the problem in a newer version of Pharo? >> (10050 is *very* old). >> >> I'd like to take a look then. It's strange because we have been >> using traits for two years now without seeing this problem. So it >> may indeed be a problem related to the UI that somehow brings >> traits into an inconsistent state. >> >> Adrian >> >> >> On Dec 2, 2008, at 11:08 , Hilaire Fernandes wrote: >> >>> I can't remove a trait from a class using UI tools. (pharo 10050) >>> How can I remove it programmatically ? >>> >>> Next with this same class, message from this trait are not >>> reachable, >>> the MNU is raised but the hierarchy is not right as IFIETayage1 is >>> not >>> a subclass of IFIExoMorph. However IFIExoMorph is using the same >>> trait >>> as IFIEtayage. >>> It looks like there is mismatch in the classes with traits. (see >>> screenshot) >>> >>> Now I realize my last istoa release suffer from this problem :) >>> >>> Hilaire >>> >>> -- >>> http://blog.ofset.org/hilaire >>> <bug-trait.png>_______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 2, 2008

Re: [Pharo-project] Monticello configuration still broken

by StÃ©phane Ducasse

It depends on what is inside MC1.5 When you load a package you load all the extensions. Stef On Dec 2, 2008, at 2:41 PM, Damien Cassou wrote: > On Tue, Dec 2, 2008 at 2:11 PM, Hilaire Fernandes > <hilaire(a)ofset.org> wrote: >> For Pharo to be a developer friendly environment, it is a must to >> include these fixes, even waiting for a better solution, because >> newbies will get burn there. > > MC1.5 already fixes all issues and I think it would be better to > integrate it than recreating it. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 2, 2008

Re: [Pharo-project] about vm dropping privileges

by Lukas Renggli

> I was rereading our excellent forthcoming seaside book :) *lol* > And lukas wrote > > "To listen on port 80, the standard port used by the HTTP protocol, > the > web server needs to run as root. Running a public service as root is > a huge security issue. Dedicated web servers such as Apache drop > their root privileges after startup. This allows them to listen to > port > 80 while not being root. Unfortunately this is not something that can > be easily done from within the Smalltalk VM. " > > And I was wondering what is the exact problem? Unix blocks port 1 - 1024 for non root users. Running a Smalltalk image as root is obviously a very bad idea, especially when used for web services. Smalltalk is full of security holes (for example Object class>>#readFrom: uses the compiler) that would allow a smart person to gain root rights. It is always good idea to run anything that is publicly reachable in some sort of a sandbox, even if this is just by using a non-privileged user. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 2, 2008

Re: [Pharo-project] a bug with Installer

by jannik.laval.gmail

Ok thanks Jannik Le 2 dÃ©c. 08 Ã 21:20, Keith Hodges a Ã©crit : > jannik.laval.gmail wrote: >> Hi all, >> >> I would run this: (present in InstallerMonticello>>basicView) >> Installer ss project: 'Installer'; view: 'Installer-Core'. >> >> But, I have an error: doesNotUnderstand: #definitions. >> >> Can anyone help me ? >> Thanks >> >> Jannik > Fixed properly with latest Monticello1.5/1.6 > > Workaround added to latest Installer for older Monticello releases > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 2, 2008

Re: [Pharo-project] a bug with Installer

by Keith Hodges

jannik.laval.gmail wrote: > Hi all, > > I would run this: (present in InstallerMonticello>>basicView) > Installer ss project: 'Installer'; view: 'Installer-Core'. > > But, I have an error: doesNotUnderstand: #definitions. > > Can anyone help me ? > Thanks > > Jannik Fixed properly with latest Monticello1.5/1.6 Workaround added to latest Installer for older Monticello releases Keith

Dec. 2, 2008