Re: [Sugar-devel] Fwd: Regarding the print support idea(GSoC)
And are the implementations not prone to modification?
As in we could specify a particular #print_port to bypass them?
On Wed, Mar 18, 2009 at 6:58 PM, Vamsi Krishna Davuluri
vamsi.davul...@gmail.com wrote:
The link you gave didn't work, so I checked this page
http://wiki.laptop.org/go/OLPC_Bitfrost
I have gone through security models listed, umm ... was there anything
specific I was to look into?
On Wed, Mar 18, 2009 at 6:42 PM, Luke Faraone l...@faraone.cc wrote:
2009/3/18 Vamsi Krishna Davuluri vamsi.davul...@gmail.com
I'd grant them only if the user is the owner of that specific document or
is master root. This will be most useful in case the machine acts as a cups
server and a request comes from the network, we could see that other than
the local master, no one else on the network has access to that particular
job, or stop that printing event from taking place.
btw thought of another thing, when the print button is clicked in an
activity, the request metadata (object) is sent to the journal, but the
journal doesnt have to immediately take over control, instead within the
activity a pop up comes which says 'print jobs in queue('this can be closed,
or clicked to go to the journal where the job can be canceled, or started)
and when loging in into sugar, if pending jobs are there again a
notification is displayed, and if a print job is of a particular activity,
and they are pending, and if the same activity is opened again it
notification is displayed.
You might want to review the OLPC project (and therefore sugar's) security
model: http://dev.laptop.org/git?p=security;a=blob;f=bitfrost.txt
--
Luke Faraone
http://luke.faraone.cc
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Regarding the print support idea(GSoC)
True enough, but I hadn't been talking about printing from activities
directly at all for the last half of the mails. :
But for even CUPS to act as a server and accept incoming requests, it would
have to excercise freedom to one port atleast, but write a bit of a code so
that it accepts requests only from local network which ever was configured
on the router. ;) And, we could specify certain pool of ips which are to
access the print server.
On Wed, Mar 18, 2009 at 7:06 PM, Luke Faraone l...@faraone.cc wrote:
On Wed, Mar 18, 2009 at 9:28 AM, Vamsi Krishna Davuluri
vamsi.davul...@gmail.com wrote:
The link you gave didn't work, so I checked this page
http://wiki.laptop.org/go/OLPC_Bitfrost
I have gone through security models listed, umm ... was there anything
specific I was to look into?
Well,
I'd grant them only if the user is the owner of that specific
document or is master root. This will be most useful in case the machine
acts as a cups server and a request comes from the network, we could see
that other than the local master, no one else on the network has access to
that particular job, or stop that printing event from taking place.
As far as I am aware, this is the default CUPS behavior.
btw thought of another thing, when the print button is clicked in an
activity, the request metadata (object) is sent to the journal, but the
journal doesnt have to immediately take over control, instead within the
activity a pop up comes which says 'print jobs in queue('this can be
closed,
or clicked to go to the journal where the job can be canceled, or started)
and when loging in into sugar, if pending jobs are there again a
notification is displayed, and if a print job is of a particular activity,
and they are pending, and if the same activity is opened again it
notification is displayed.
And are the implementations not prone to modification?
As in we could specify a particular #print_port to bypass them?
Allowing activities to print things directly is just asking for trouble.
Potential attack vector: an activity that has RO access to all documents but
is denied net access (per their mutual-exclusiveness specified by bitfrost)
has the ability to send outgoing requests to port 5900 (HP JetDirect port),
per your printing exception. A black hat, who authored this application,
sets up a print server at death.example.com. Since the activity can send
any packet it wishes on that port, it simply prints to this server. The
attacker now has subverted the bitfrost model, and now has access to all of
the user's documents.
--
Luke Faraone
http://luke.faraone.cc
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Regarding the print support idea(GSoC)
Ah, that was the thing I had not understood with the extra credits that were given. I had thought that functionality had to be added to each desktop so it would act as a print server. sorry. Clarify a few things for me : What exactly was required/meant from/by a print server? I was in the opinion that each laptop was supposed to act as server for the network :P And do we have a powerful server that can act as a print server (which accepts requests from network, assuming we require network printing)? And thanks, yes, I have been reading that pdf. I was also thinking using python-gnome bindings (which are available) to simulate a gnome tool menu. But this seems better! On Wed, Mar 18, 2009 at 8:59 PM, Luke Faraone l...@faraone.cc wrote: 2009/3/18 Vamsi Krishna Davuluri vamsi.davul...@gmail.com True enough, but I hadn't been talking about printing from activities directly at all for the last half of the mails. : But for even CUPS to act as a server and accept incoming requests, it would have to excercise freedom to one port atleast, but write a bit of a code so that it accepts requests only from local network which ever was configured on the router. ;) And, we could specify certain pool of ips which are to access the print server. Maybe I'm not understanding you properly: is there a reason that we can't use the standard CUPS daemon on our print server? Are you saying that the individual Sugar desktop should act as a server for *everyone else* in the network? CUPS servers should, imho, be left up to the network administrator to configure; it is beyond the scale that a child would need to perform on their local workstation. Sugar's role should be to offer configuration of printers that the local system is able to access. You can probably add an extension/plugin to the control panel which wraps Debian's system-config-printerhttp://packages.debian.org/sid/system-config-printer, which is written in Python and has (AFAICT) no extra dependancies other than what sugar already requires. Added/autodetected printers can appear in the network view as devices, if you want extra bonus points :) -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Regarding the print support idea(GSoC)
2009/3/18 Vamsi Krishna Davuluri vamsi.davul...@gmail.com Clarify a few things for me : What exactly was required/meant from/by a print server? I was in the opinion that each laptop was supposed to act as server for the network :P It seems I misunderstood *you*. That makes sense, it just was that the way it was worded suggested that *activities* could communicate on that port. And do we have a powerful server that can act as a print server (which accepts requests from network, assuming we require network printing)? Yes, the School Server (XS). And thanks, yes, I have been reading that pdf. I was also thinking using python-gnome bindings (which are available) to simulate a gnome tool menu. Yes, we try to shy away from too many dependencies on GNOME (which increases the size of our installs on XOs) -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Regarding the print support idea(GSoC)
Ben, are you going to be mentoring this project? Or is there a *possible* mentor I can discuss about this on the IRC channel? On Mon, Mar 16, 2009 at 6:06 PM, Benjamin M. Schwartz wrote: Vamsi Krishna Davuluri wrote: Thank you! I think I'll do what you said, I'll just let every activity send the print request(the file,metadata involved etc) to journal, and use it as a global dock to print the file. So a button in every activity does just that with minimal tweaking around. Did you mean the 'difficult than is necessary' by this, or is there a grand ring to it, which i need to check again? That's all I meant. Good luck. --Ben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Regarding the print support idea(GSoC)
On Wed, Mar 18, 2009 at 10:59 AM, Vamsi Krishna Davuluri vamsi.davul...@gmail.com wrote: After talking to tomeu, and discovering the pygtk print api,(which through backends interacts with the cups api) I think its okay to just include the cups api, and then on top of pygtk print (which has modules like page setup, printer setup etc) make a nice new tab/ or pop out menu(dialog) in the journal which allows configuration. We an even install rights for the bit advanced printing functionalites if needed. I think most of the postscript editing is taken care by pygtk print, I'll do a bit of research here, if not its just simple text editing of the PPD (wiki said that, need to do a bit more work here too) :D On Wed, Mar 18, 2009 at 3:36 AM, Luke Faraone l...@faraone.cc wrote: Sorry, I accidentally pressed send before I had finished! :) On Mon, Mar 16, 2009 at 1:50 AM, Vamsi Krishna Davuluri vamsi.davul...@gmail.com wrote: Thank you! I think I'll do what you said, I'll just let every activity send the print request(the file,metadata involved etc) to journal, and use it as a global dock to print the file. So a button in every activity does just that with minimal tweaking around. Makes sense. One should be careful to not expose the CUPS service to activities directly, as one of the threats we have to worry about is resource abuse. Ideally (IMHO), pressing print should have the object sent via the dbus to the journal and a preview dialog with a to menu and a options dialog (which brings up the properties configurable by the driver). On Mon, Mar 16, 2009 at 1:27 AM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: [...] Perhaps in the drop-down menu for each item in the Journal, there could be a Print this item option if the item has a MIME type of (pdf, odt, png, jpg...). Yes, it would be a good idea to have a list of supported print formats for simplicity. PostScript, of course, should be supported as a fallback. -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Fwd: Regarding the print support idea(GSoC)
Hello, A Student trying to get into GSoC here After a bit of research I have come up with this approach for the mandatory requirements that a printer would assume to comply. 1)Integration of a printing infrastructure (CUPS ??) into the XO-1 software images - pycups is an opensource based wrapper around cups, we could include the bindings. Or write bindings entirely from the scratch tailored to serve the purpose And write a sugar.printer module, which again fits the guidelines, and communicates through D-BUS with applications 2) Modification of Sugar Control Panel to set up the printer (add/select default printer?) write a pygtk code so that a new tool button is made available, and on pressing, a menu box pops out, and connect the buttons to the specific handlers 3)Extra credit: integrating a server, including permissions and quota management, into the XS image. The CUPS api allows the machine to act as a print server, and the cups api includes a default quota management system. or am i missing something Thank You, IwikiwI (Vamsi Krishna Davuluri) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
