Title: Untitled Document
¢Á º»¸ÞÀÏÀº Á¤º¸Åë½Å¸Á ÀÌ¿ëÃËÁø ¹× Á¤º¸º¸È£ µî¿¡ °üÇÑ ¹ý·ü Á¦ 50Á¶¿¡ ÀÇ°ÅÇÑ [±¤°í] ¸ÞÀÏÀÔ´Ï´Ù.
¢Á e-mail ÁÖ¼Ò´Â ÀÎÅͳݻ󿡼 ÃëµæÇÏ¿´À
Title: bdvd.co.kr
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Title: Untitled Document
http://www.sohomart.org
º» E-mailÀº Á¤º¸Åë½ÅºÎ ±Ç°í¾È¿¡ µû¶ó °ø°³µÈ °Ô½ÃÆÇ µî¿¡¼
ȹµæÇßÀ¸¸ç ¼ö½ÅÀÚ²²¼
¼ö½Å°ÅºÎ
Àǻ縦 ¹àÈù ÈÄ¿¡´Â ´Ù½
Title: <Çѱ¹ÇÁ·Úº§(ÁÖ)>Àá¿øÁö±¹/º»ºÎÀå : ±è Áö ¿ìÀüÈ : 011-243-5304
<Çѱ¹ÇÁ·Úº§(ÁÖ)>
Àá¿øÁö±¹/º»ºÎÀå : ±è Áö ¿ì
ÀüÈ : 011-243-5304
º» ¸ÞÀÏÀº Á¦¸ñ¿¡ ±¤°í¶ó°í Ç¥±âÇÑ ±¤°í¸ÞÀÏÀ̸ç 1ȸ¼º ¸ÞÀÏÀÔ´Ï´Ù.
___
Bug-hurd mailing list
[EMAIL PRO
On Tue, May 14, 2002 at 09:06:44PM -0400, Roland McGrath wrote:
> The file_exec call on the interpreter (sh) is where it goes from there.
> That in turn results in an ordinary exec_exec of the interpreter file.
> If you're unclear on what happens after that, read exec.c:do_exec,
> S_exec_startup
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Advanced Mass Sender 4.0b - ñàìàÿ áûñòðàÿ è
óäîáíàÿ ïðîãðàììà äëÿ ìàññîâîé email ðàññûëêè !
http://www.massender.com
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Title: ºñȸ¿ø3_1
½Ã´ëÀÇ
> Right, but I think the same thing is true in the case of fakeroot. At
> least, I think so unless there is some clear reason why it should face
> io_identity.
If you'd been following the discussion you'd have noticed that this came up
in the context of #! exec's lookup of the script file name.
> Ha, that was way too easy with rpctrace. It turns out that /dev/fd/3 is
> looked up in the namespace of the fakeroot translator, which conveniently,
> but in a fundamentally broken way looks up the node and does all the MAGIC
> interpretation itself.
Duh. One of these days I will switch my br
Roland McGrath <[EMAIL PROTECTED]> writes:
> > Right, but I think the same thing is true in the case of fakeroot. At
> > least, I think so unless there is some clear reason why it should face
> > io_identity.
>
> If you'd been following the discussion you'd have noticed that this came up
> in t
Roland McGrath <[EMAIL PROTECTED]> writes:
> We have to implement
> netfs_S_dir_lookup ourselves, so that it can return partial results using
> FS_RETRY_MAGICAL to the user.
I think this is generally true for weird things like fakeroot. Back
when, this was my general intention for weird thing
> But isn't this connected to the case of whether the /dev/fd method
> works? If we make that method work, then the io_identity check isn't
> necessary, right?
The other method is still preferable.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://ma
Title: ºñȸ¿ø3_1
½Ã´ëÀÇ
Title: °¹¹Ù±¸ ±¼±¸ÀÌ Àü¹®Á¡
µ¹»ê´ë±³
Roland McGrath <[EMAIL PROTECTED]> writes:
> > But isn't this connected to the case of whether the /dev/fd method
> > works? If we make that method work, then the io_identity check isn't
> > necessary, right?
>
> The other method is still preferable.
Hrm, I'm beginning to wonder whether the me
> Hrm, I'm beginning to wonder whether the mere fact that fakeroot can
> fake this doesn't mean that the io_identity check isn't sufficient for
> the security that #! execution needs...
It only needs security for EXEC_SECURE, in which case a) it doesn't use
that code (always /dev/fd), and b) you
Roland McGrath <[EMAIL PROTECTED]> writes:
> > Hrm, I'm beginning to wonder whether the mere fact that fakeroot can
> > fake this doesn't mean that the io_identity check isn't sufficient for
> > the security that #! execution needs...
>
> It only needs security for EXEC_SECURE, in which case a)
> Ok. For the normal case, why do we bother with the io_identity check
> at all?
To ensure correctness when noone is lying but for whatever reason the name
does not actually match (such as the race).
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http:
Title: ¹é¸¸ÀåÀÚŬ·´ ¼Ò½ÄÁö 5¿ù
¹é¸¸ÀåÀÚŬ·´ ¼Ò½ÄÁö5¿ù
óÀ½ºÎÅÍ ºÎ¿Í ¼º°øÀ» °Å¸ÓÁã°í ÅÂ¾î³ »ç¶÷Àº ¾ø¾ú´Ù.
´ç½ÅÀº Ȥ½Ã ½¢ÇÏ°Ô Ã£¾Æ¿Â ¼º°øÀ» ŸÀκ¸µíÁö³ªÃÄ¿Â °ÍÀº ¾Æ´Ñ°¡
¿À´ÃÀ» ¾îÁ¦º¸´Ù ´Ù¸£°Ô »ì¾Æ°¡´Â ¹æ¹ýÀ»
¾Õ·ÁÁÖ´Â Èñ¸ÁÀÇ Ã¥-º»¹®³»¿ë Áß¿¡¼*
ÃֽŠ±â»ç
¹é¸¸ÀåÀÚŬ·´
I had been using the mainline of gcc cvs but lately it has been flakey.
So I don't recommend that for Hurd cross-compiling at this point. It's
safer to stick to gcc-3.1, which AFAIK is fine vanilla for i?86-gnu. These
patches to gcc-3.1 add the alpha-gnu target support (which will already be
i
º» ¸ÞÀÏÀº Á¤º¸Åë½ÅºÎ ±Ç°í »çÇ׿¡ ÀÇ°Å Á¦¸ñ¿¡
[±¤°í]¶ó Ç¥½ÃµÈ ±¤°í ¸ÞÀÏÀÔ´Ï´Ù.¼ö½Å°ÅºÎ
¹öÆ°À» Ŭ¸¯ÇÏ½Ã¸é ¼ö½Å°ÅºÎ󸮰¡ ÀÌ·ç¾î Áý´Ï´Ù.
Á¦ÁÖ¿©Çà,
Á¦ÁÖÇöÁö¿©Çà»çÀÔ´Ï´Ù,
¿©¸§ ÈÞ°¡Ã¶ ¿¹¾àÀ» ¹Þ°íÀÖ½À´Ï´Ù,
Ç×°ø,Äܵµ,¹Î¹Ú,´Üü¿©ÇàÀú·ÅÇÑ°ßÀû,16ÀνÂ,31ÀνÂ.45ÀνÂ
Àü¼¼¹ö½º
¼ö³îÀ½¿©Çà»çPKG»óÇ°
Á¤¸»·ç,½Å¼±ÇÑ Ãæ°Ý 2ź ÀÔ´Ï´Ù.
¾È³çÇϼ¼¿ä? Àú¹ø¿¡ Çѹø ÀÎ»ç µå·È´ø Áß¾ÓÅ׸¶À̺¥Æ® ´ã´ç ±èÀ±Èñ ¶ó°í Çϴµ¥¿ä,
±â¾ï ÇϽôÂÁö¿ä??.
ÀÌÁ¦ ³¯¾¾µµ ÁÁ°í ±âºÐµµ °¡º¿î ¿äÁò~ µü~~ÁÁÀº Çà»ç°¡ ÀÖ¾î
´Ù½ÃÇѹø ¸á µå¸³´Ï´Ù.(ÀúÈñ ȸ¿øÀ̽źе鵵 ³¡±îÁö Àоî ÁÖ¼¼¿ä~~*^^*)
¿äÁ¡¸¸,¸»¾¸µå¸®¸é-Àú¹ø¿¡ ÀÌÀº ¾÷±×
24 matches
Mail list logo
