Re: environment / screen / X
--- David Walter <[EMAIL PROTECTED]> wrote: > > I ran into a strange problem today when running x under the hurd. > > I noticed that I was not able to load some programs under X as a user. > > At first I thought that this was a user vs root permissions problem > because I hadn't seen this under the root login. > > But I found out by ldd'ing some of the programs and verifying that the > LD_LIBRARY_PATH was correctly configured to point to /X11R6/lib for > the user account that ldd _failed_ to find libX11.so even with the > correct LD_LIBRARY_PATH. > These binaries that you can't run are suid, so LD_LIBRARY_PATH is ignored. = James Morrison University of Waterloo Computer Science - Digital Hardware 2A co-op http://hurd.dyndns.org Anyone referring to this as 'Open Source' shall be eaten by a GNU __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: saved IDs and exec (standard violation?)
Roland McGrath <[EMAIL PROTECTED]> writes: > The only drawback I see is in the case when svuid!=euid or svgid!=egid, and > you are executing an sugid file. The user will reauthenticate everything > for the svuid=euid, svgid=egid change and then the filesystem will > reauthenticate everything again to do the suid/sgid. So, a sugid program > that execs another sugid program directly without an intervening exec of a > non-suid program--a pretty rare event, I would guess. I'm happy to gunk up setuid execs with however many extra RPCs as long as normal execs can remain speedy. > > But there might be a security reason why we have to force the change > > to be made. But I can't possibly see what that would be. > > I don't think any concept of security is sensical for non-sugid execs with > EXEC_SECURE. The user who made the call will always be able to grab the > process by its scrawny little task port and diddle its ports out the wazoo. Exactly my thinking. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: iohelp handle_io_release_conch doesn't lock shared page
Roland McGrath <[EMAIL PROTECTED]> writes:
> We do. The virtual copying behavior is enabled by a Boolean argument to
> vm_map. The issue is having several mappings together as an atomic unit
> relative to intervening write calls (or modifications via shared
> mmap).
One could get the (suckish) linux behaviour by somehow locking the
file at the start of the exec processing, and releasing it at process
death or exec.
> One idea is a call like `io_snapshot' that creates a new port
> that gives read-only access to the state of the node as it was when
> snapshot'd. It would be unduly hairy to implement the file-data part of
> that in the filesystem, except by using vm_copy_object (which doesn't exist).
That sounds quite similar to implementing versioning in the
filesystem. Something like setting a snapshot-flag on the inode, and
at the next write to the file, you create a new inode that's copy of
the snapshot (either a full copy or some copy-on-write thing).
As the common case should be that the file you have a snapshot of is
*not* written to, I think it would be acceptable to make a full copy
at the first write.
But one case that snapshotting does not solve, as far as I can tell,
is the following:
fd = open ("/bin/bash", O_WRONLY | O_TRUNC | CREAT);
write(fd, first half of the binary);
exec("/bin/bash", ...); /* By some other process */
write(fd, second half of the binary);
To me it seems, one must also make sure that the snapshot is made at a
moment when no process have the file open for writing (or more
prceisely: There's no process that has written data to the file, and
still has the file open for writing).
If some useful snapshoting is ever implemented, it would be nice to be
able to get a snapshot by just opening the file with O_RDONLY |
O_SNAPSHOT.
I agree it seems quite hairy to get it both robust and reliable.
/Niels
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
[±¤°í]5ºÐ¸¸¿¡ °ú¿Ü ±¸Çϱâ!!!
Title: Untitled Document º»¸ÞÀÏÀº Á¤ÅëºÎ ±Ç°í»çÇ׿¡ ÀÇ°Å Á¦¸ñ¿¡ [±¤°í] ¶ó°í Ç¥±âµÈ ¸ÞÀÏÀÔ´Ï´Ù. º»¸ÞÀÏÀº ¹ß½ÅÀü¿ë ¸ÞÀÏÀÔ´Ï´Ù À̸ÞÀÏÀº ÀÏȸ¼º ¸ÞÀÏÀ̸ç Àç¹ß¼ÛµÇÁö ¾Ê½À´Ï´Ù. ±ÍÇÏÀÇ ¸ÞÀÏÁÖ¼Ò´Â À¥¼ÇÎÁß¿¡ ¾Ë°ÔµÈ °ÍÀ̸ç, À̸ÞÀÏ ÁÖ¼Ò¿Ü¿¡ ´Ù¸¥ Á¤º¸´Â °¡Áö°í ÀÖÁö ¾Ê½À´Ï´Ù. ¿øÄ¡ ¾ÊÀ¸½Ã¸é ¼ö½Å°ÅºÎ¸¦ ´·¯ÁÖ¼¼¿ä copyright(c)2001 niceguide. all rights reserved. mail to webmaster ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Do you have enough Life Insurance? UDFK
Since 1996, term life insurance rates have been reduced by as much as 70% !40 year old male - $250,000 - 10 year level term As low as $10.45 per month !At TermQuotes Life Insurance Companies of America, we will survey the top life insurance companies for you and provide you with the best rates available. Compare the rates and see for yourself. Fill out this quick form below for further information.The quote is FREE. There is no obligation to buy.Results of computer survey 05-09-02 Sample Annual Premiums* 10 Year Level Premium Term Rates *Age$250,000$500,000$1,000,00035$115$175$30545$210$375$67055$500$935$1,37065$1,305$2,550$4,92070$2,265$4,480$7,510 *Above rates guaranteed to remain level for 10 yearsRates based on male preferred class 1 non-smoker Policies are guaranteed renewable to age 95Policies with 15, 20, 25, and 30 year level premiums also available.Universal Life, Second-to-Die and Estate Planning products also provided.Attention All Smokers: You may qualify for special reduced smoker rates!Submit This Form for a Free Term Insurance Quote !Name Insured: Amount of Coverage: $250,000$300,000$400,000$500,000$600,000$700,000$800,000$900,000$1,000,000Date of Birth: Month 010203040506070809101112 Day 01020304050607080910111213141516171819202122232425262728293031 Year Sex: Male Female Height: FT in Weight: lbs.Occupation: xxxHave You Ever Had:High Blood Pressure: Yes No Heart Attack or Stroke: Yes No Cancer: Yes No Diabetes: Yes No Have You Smoked Within the Last 12 Months: Yes No xxxPerson Completing Request: Mailing Address: City: State Zip Daytime Phone: Evening Phone: Email Address: Best time to contact: Morning After noon Evening Weekend When you click submit it may activate your spell check, please click "Ignore" if it does. YOUR INTERNET ADVERTISING Copyright 1996-2002. All Rights Reserved This could be your ad!Email Us for free quotes and consultations.If you think that you will not benefit from this correspondence, please reply with 'remove' as the subject. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: saved IDs and exec (standard violation?)
On Sat, May 11, 2002 at 10:28:19PM -0400, Roland McGrath wrote:
> Just to keep the record straight, I was talking about having the filesystem
> implementing file_exec do it (that's where the only auth diddling is, the
> exec server doesn't do it). But having the user do it is a better plan. I
> don't know why I didn't think of that in the first place. It avoids the
> whole issue of the filesystem having to either trust or deal with a
> user-supplied auth port even with a svuid/svgid change is required.
I agree. This was actually my first thought about how to fix it ("It seems
to be merely an issue of the default behaviour in glibc, ..."), because
obviously the task already has all the privileges it is leaking, and as such
there is no real security leak in the system, but only at the user's side.
In Unix, there doesn't seem to be a way to change the saved ID other than
changing the effective ID and do a fork(). In the Hurd, we can do better,
it seems. Maybe we can even have setsuid,getsuid,setsgid,getsgid? Seems to
be a straightforward addition at least, although I am not sure of what use
it will be when exec resets them.
> The only drawback I see is in the case when svuid!=euid or svgid!=egid, and
> you are executing an sugid file.
I agree, this is not a common thing to do at all. Might happen with a game
that starts a sound daemon, or things like that.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: environment / screen / X
On Sun, May 12, 2002 at 01:15:47AM -0400, David Walter wrote: > But I found out by ldd'ing some of the programs and verifying that the > LD_LIBRARY_PATH was correctly configured to point to /X11R6/lib for > the user account that ldd _failed_ to find libX11.so even with the > correct LD_LIBRARY_PATH. If the sgid/suid bit is set for a binary, and you don't have the permission those bits indicate, then LD_LIBRARY_PATH is ignored. > No screen, no libX11. > with screen, -> libX11. reported found. Now the interesting thing is that the Hurd has a bug that makes screen leak the utmp group permission. screen itself is sgid+utmp, and this group permission as the saved ID leaks through into the shell it spawns. As a consequence, your user has utmp group permission inside screen (try it out by running "ids" in screen). And the sgid flag for many xterm's is exactly to ge them utmp permissions. As you already have those permissions, the LD_LIBRARY_PATH doesn't need to be ignored now. You have a shell. Enjoy this bug as long as you can, because when we will fix it, you will get the correct, non-functional behaviour even with screen ;) (You could give your user root or utmp permission with addauth at any time, if you are root, for example). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: saved IDs and exec (standard violation?)
On Sun, May 12, 2002 at 02:24:24PM +0200, Marcus Brinkmann wrote: > In Unix, there doesn't seem to be a way to change the saved ID other than > changing the effective ID and do a fork(). exec(), not fork(), of course. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
¼¿ï°æ±â ¿©¼ººÐ¸¸º¸¼¼¿ä ¹«·áÀ̺¥Æ®[±¤°í]
Title: mail * ÀÌ Çà»ç´Â ¹«·á À̺¥Æ® Çà»çÀÔ´Ï´Ù. * 20¼¼ ÀÌ»óÀÇ ¼¿ï,°æ±â,ÀÎõ Áö¿ª °ÅÁÖ ¿©¼ººÐ¿¡ ÇÑÇÏ´Ï ÀÌÁ¡ ¾çÇعٶø´Ï´Ù. 1µî : ¹ÙÀÌ¿Àµð ¸ÖƼũ¸² set [ 17¸¸¿ø »ó´ç ] 2µî : À̸𶼠¸µÅ¬ÆÄ¿öÆ®¸®Æ®¸ÕÆ® ±âȹset [ 10¸¸¿ø »ó´ç ] 3µî : À̸ð¶¼4Á¾ ½ºÆä¼È ±âȹset [ 7¸¸¿ø »ó´ç ] 4µî : ¾ÆÀ̵ð¾ó Ä®¶óÁî [ 4¸¸¿ø »ó´ç ] / 5µî : ÈÀÌÆ® ¹ë·±½Ì ¸¶½ºÅ© [ 3¸¸¿ø »ó´ç ] ½ºÅ²Äɾî ÀÌ¿ë±Ç [10¸¸¿ø »ó´ç] ÁõÁ¤ LG FABIANNE ºäƼ¼¾ÅÍ¿¡¼ TSMS programsÀ» ÅëÇÑ °úÇÐÀûÀÎ ÇǺΠºÐ¼®°ú Áø´ÜÀ» ¹«·á·Î Çص帳´Ï´Ù. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: fakeroot problem
On Sun, May 05, 2002 at 04:27:47PM -0400, Roland McGrath wrote:
> Oh, that EISDIR must be from opening with write permission in
> netfs_attempt_lookup. I made it check for EROFS or EISDIR as it does for
> EACCES. If there are other possible errors for an O_RDWR open that aren't
> possible for a O_RDONLY open, we should check for those as well. Or we
> could make it just ignore any error except for some common cases like
> ENOENT in the first two tries and only report the error on the third. But
> I'd rather not repeat the calls for most errors if we can avoid it.
It is amazing from where these things crop up. I have now found the problem
with the chroot() case. In fact, it had nothing to do with settrans, and it
had nothing to do with chroot either.
The problem is symbolic links. We get ENOTDIR from file_name_lookup_under
when trying to open a symbolic link to a file with the O_EXEC bit set, and
we don't catch this in netfs_attempt_fakeroot. I have not verified it, but
had I to venture a guess I would say this comes from the EOPNOTSUPP in
diskfs's dir_lookup:
/* Check permissions on existing nodes, but not new ones. */
{
if (((type == S_IFSOCK || type == S_IFBLK || type == S_IFCHR ||
type == S_IFIFO)
&& (flags & (O_READ|O_WRITE|O_EXEC)))
|| (type == S_IFLNK && (flags & (O_WRITE|O_EXEC
error = EOPNOTSUPP;
I have worked around this in netfs_attempt_lookup by ignoring ENOTDIR if we
try to open with O_EXEC, but this doesn't look quite right. Is there a
better fix? Why are we looking up with O_NOLINK anyway?
Also, from looking at the above code, looking up any socket, fifo or other
special device will fail in netfs_attempt_lookup, with the same error. If
my work around was correct, then we need to always ignore ENOTDIR. And,
another thing, shouldn't we try to lookup the node in netfs_attempt_lookup
with O_NORW as a very last resort?
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
[±¤°í] À̸¸ÇÑ ºÎ¾÷ ¾ø½À´Ï´Ù.
Àοø ±Ý¾×(¿ø) Àοø ±Ý¾×(¿ø) 5 21,125 8 43,400 25 100,625 64 257,600 125 503,125 512 2,060,800 625 2,515,625 4,096 16,486,400 °è 3,146,500 °è 18,848,200 ´ÙÀ½´ÞºÎÅÍ À籸¸ÅÈÄ¿ø¼ö´ç 186¸¸¿ø ´ÙÀ½´ÞºÎÅÍ À籸¸ÅÈÄ¿ø¼ö´ç 686¸¸¿ø »Ñ¸®È¸¿ø °¢ÀÚ 5¸í Ãßõ½Ã °¢ÀÚ 8¸í Ãßõ½Ã Àοø ±Ý¾×(¿ø) Àοø ±Ý¾×(¿ø) 5 54,250 8 86,800 25 201,250 64 515,200 125
fakeroot status
Hi, I have done a few tests. fakeauth works with spawni.c from the glibc 2.3 (HEAD) branch. Roland, any plans to put this into the 2.2 branch? We can probably do this only for the Debian package, too. (The reason it doesn't work right now is that fork() creates a new receive right for the faked auth port, and so it is not inherited correctly. The generic spawni in 2.2 is based on fork+exec, while the sysdeps/mach/hurd/spawni.c in HEAD is not based on fork() at all. The difference should either be fixed by changing fork() or documented because spawni and fork+exec behave differently here). The fakeroot translator, see the other mail of today, there is a problem with symlinks. Then there is a problem in that many RPCs are not passed through. So pipes to the fakeroot world don't work, for example, and bash complains about that. So we need a message deflector for all unrecognised RPCs in the demuxer. Can we also deflect all RPCs that currently return EOPNOTSUPP? Or do we need to provide individual pass through functions for all functions in a subsystem we can not deflect entirely? settrans --chroot works fine. The fakeroot utility: It works within the limitation above, but not as the GNU/Linux fakeroot utility. The difference is that with fakeroot, you end up in the directory /, whereas the fakeroot utility in GNU/Linux does not change your current directory. How do we fix that best? Maybe provide a "--chroot-chdir" option to settrans that puts us into the directory specified? Than we can put "--chroot-chdir `pwd`" into the fakeroot script. I think that is all, but for more testing I need the message deflector. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: fakeroot status
> fakeauth works with spawni.c from the glibc 2.3 (HEAD) branch. Roland, any
> plans to put this into the 2.2 branch?
Definitely not. I don't think you should use it for the debian version
either. That code is too young. What we can do is make fakeauth use the
underlying hurdish stuff directly instead of either fork or spawn.
> Then there is a problem in that many RPCs are not passed through. So
> pipes to the fakeroot world don't work, for example, and bash complains
> about that. So we need a message deflector for all unrecognised RPCs in
> the demuxer. Can we also deflect all RPCs that currently return
> EOPNOTSUPP? Or do we need to provide individual pass through functions
> for all functions in a subsystem we can not deflect entirely?
The way mig demuxing works, you have to choose at the subsystem granularity
(unless you want to do ugly kludges). So we need individual pass-through
server functions for all the stubs in netfs.
I added a netfs_demuxer function in fakeroot.c that does the basic
forwarding of unrecognized messages. Modulo simple bugs, I think that will
work for the socket servers. It's questionable for the general case,
because it always uses just the one port on the underlying node and sends
messages from all peropens there. If there are other-protocol messages
that diddle peropen state, then the behavior from this will be pretty
bizarre in the face of multiple fakeroot peropens with different users. An
approach that would make more sense for that would be to have a different
underlying node port for each peropen. e.g., new_node could do a NORDWR
lookup and then each new peropen could do a dir_lookup ("",...) with its
appropriate openmodes to get a new corresponding peropen. But that would
require adding some space to netfs's struct peropen, and it just generally
doesn't fit the existing netfs model so well. We can probably punt that
issue if we are only thinking about the socket servers and the /dev devices.
> settrans --chroot works fine.
Glad to hear it.
> The difference is that with fakeroot, you end up in the directory /,
> whereas the fakeroot utility in GNU/Linux does not change your current
> directory.
I made the --chroot option work like the chroot command does, which is to
say chdir ("/") after the chroot. I think the thing to do is just handle
it in the subprocess. i.e., run sh -c "cd `pwd`; ...".
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: fakeroot problem
> The problem is symbolic links. We get ENOTDIR from file_name_lookup_under > when trying to open a symbolic link to a file with the O_EXEC bit set, and > we don't catch this in netfs_attempt_fakeroot. I have not verified it, but > had I to venture a guess I would say this comes from the EOPNOTSUPP in > diskfs's dir_lookup: That seems like a reasonable deduction. I've made fakeroot treat EOPNOTSUPP like EACCES here. I also made it try zero openmodes if all else fails. However, I think diskfs should not return EOPNOTSUPP for this case. On Unix systems I have tried, trying to execute a device file (that has execute bits set) fails with EACCES. That seems like the appropriate error for attempting to open a symlink for execute access as well (though on Unix there is no way to attempt that). ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: fakeroot status
On Sun, May 12, 2002 at 03:51:09PM -0400, Roland McGrath wrote:
> Definitely not. I don't think you should use it for the debian version
> either. That code is too young. What we can do is make fakeauth use the
> underlying hurdish stuff directly instead of either fork or spawn.
Well, ok. I will use my locally compiled glibc for a while, but it is
difficult to get it tested with hardly anything using posix_spawn. So this
is an incentive for me to compile bash, make and gcc using posix_spawn and
give this code some testing.
> The way mig demuxing works, you have to choose at the subsystem granularity
Ok.
> I added a netfs_demuxer function in fakeroot.c that does the basic
> forwarding of unrecognized messages. Modulo simple bugs, I think that will
> work for the socket servers.
Cool, I started implementing it when I noticed that it isn't too easy to
construct the mach_msg call from the inp.
I think I found a bug already, you use inp->msgh_local_port, but I think
inp->msgh_remote_port is the port local to the server (which I also used in
libpager/demuxer.c). From mach/message.h:
* The msgh_remote_port field specifies the destination of the message.
* It must specify a valid send or send-once right for a port.
*
* The msgh_local_port field specifies a "reply port". Normally,
* This field carries a send-once right that the receiver will use
* to reply to the message. It may carry the values MACH_PORT_NULL,
* MACH_PORT_DEAD, a send-once right, or a send right.
Likewise, I think that the msgh_local_port should be unchanged, so the
other server sends the reply directly to the user.
I have to think more about the problems that this doesn't solve.
> > The difference is that with fakeroot, you end up in the directory /,
> > whereas the fakeroot utility in GNU/Linux does not change your current
> > directory.
>
> I made the --chroot option work like the chroot command does, which is to
> say chdir ("/") after the chroot. I think the thing to do is just handle
> it in the subprocess. i.e., run sh -c "cd `pwd`; ...".
This needs to be in utils/fakeroot.sh, then, so it always spawns a shell and
runs the command inside the shell after the cd. Blech. What I did as a
quick hack was to do the same on the user side (eg in dpkg-buildpackage),
and it seemed to work.
Thanks (going to test the demuxer changes),
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: fakeroot problem
On Sun, May 12, 2002 at 03:59:23PM -0400, Roland McGrath wrote: > That seems like a reasonable deduction. I've made fakeroot treat > EOPNOTSUPP like EACCES here. But we get ENOTDIR because of lookup_error mangling, not EOPNOTSUPP. > I also made it try zero openmodes if all else > fails. Thanks. > However, I think diskfs should not return EOPNOTSUPP for this case. I think I agree. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: fakeroot problem
> On Sun, May 12, 2002 at 03:59:23PM -0400, Roland McGrath wrote: > > That seems like a reasonable deduction. I've made fakeroot treat > > EOPNOTSUPP like EACCES here. > > But we get ENOTDIR because of lookup_error mangling, not EOPNOTSUPP. Oh, right. I wasn't thinking about file_name_lookup_under in the translator. I don't think we want netfs_attempt_lookup to treat all ENOTDIR errors as possibly recoverable, though. That's what you'd get for looking up "foo/bar" when foo is not a directory. So I think I will just fix diskfs. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: fakeroot status
> Well, ok. I will use my locally compiled glibc for a while, but it is > difficult to get it tested with hardly anything using posix_spawn. So this > is an incentive for me to compile bash, make and gcc using posix_spawn and > give this code some testing. Getting stuff to use posix_spawn is a fine goal. When glibc 2.3 gets ready for testing, it will plop in with those binaries and replace the fork-based implementation with the new Hurdish one. As to fakeauth, I just checked in the change to make it use _hurd_exec directly instead of using posix_spawnp. Unless I fouled that up, that ought to make fakeauth work with stock libc as well as it does with the new posix_spawn you have been using. > Cool, I started implementing it when I noticed that it isn't too easy to > construct the mach_msg call from the inp. Sure it is. > Likewise, I think that the msgh_local_port should be unchanged, so the > other server sends the reply directly to the user. Nope. The fields are swapped on the way through the kernel, so you have to swap them back. See rpctrace. > I have to think more about the problems that this doesn't solve. Do you mean the issue of peropen state that I mentioned, or something else? > This needs to be in utils/fakeroot.sh, then, so it always spawns a shell and > runs the command inside the shell after the cd. It can exec after cd. The Linux fakeroot script runs sh -c "$*" too (even though there it has no reason not to save the process and get the quoting right). I checked in a change. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
µçÄÔÅä¼þ ( ´óÌØ¼Û )
ÄãºÃ£¡ ̨Í廪·áÉÌÎñ¹«Ë¾ÔÚ´ËÏÈ×£ÄãÉúÒâÐË¡£¬ÊÂÊÂ˳Ò⣡ÎÒ¹«Ë¾³¤ÆÚ¾ÓªµçÄÔÅä¼þ¼°ÊÖ»úÓûÔÚ¹óµØÑ°ÕÒÏúÊÛ´°¿Ú£¬±¾¹«Ë¾¿ÉÌṩËÍ»õ£¬²¢±£Ö¤ËùÌṩµÄ»õÆ·ÊÇÈ«ÐÂÔ×°²úÆ·,Èç¹ó·½·¢ÏÖ²úÆ·ÖÊÁ¿ÎÊÌâ¿É¾Ü¾ø¸¶¿î¡£ÓÐÒâÕßÀ´ÈËÀ´µçǢ̸¡£ ÁªÏµÈË£ºÐíÍþÈÊÁªÏµµç»°£º £¨0£©13860731885 һؼCPUϵÁÐ: (µ¥Î»:Ôª) ±¼ÌÚ¢ó 866EB Socket 370/256K/É¢×° 370 ±¼ÌÚ¢ó 933 Socket 370/256K/É¢×° 390 ±¼ÌÚ¢ó 1G Socket 370/256K/É¢×° 480 ±¼ÌÚ¢ó 1.2 Socket 370/TualatinºËÐÄ/256K/É¢×° 400 ±¼ÌÚ4 1.4G Socket 423/256KB/400Õ×/É¢×° 420 ±¼ÌÚ4 1.5G Socket 478/256KB/400MHz /ºÐ×° 450 ±¼ÌÚ4 1.6G Socket 478/256KB/400MHz/ºÐ×° 460 ±¼ÌÚ4 1.7G Socket 478/256KB/400MHz/ºÐ×° 550 ±¼ÌÚ4 1.8G Socket 478/256KB/400MHz/ºÐ×° 700 ±¼ÌÚ4 1.9G Socket 478/256KB/400MHz/ºÐ×° 1150 ±¼ÌÚ4 2.0G Socket 478/256KB/400MHz/ºÐ×° 1200 ÈüÑï1000A Socket 370/TualatinºËÐÄ/256K/É¢×° 245 ÈüÑï1.2 Socket 370/TualatinºËÐÄ/256K/É¢×° 270 ÈüÑï1.3 Socket 370/TualatinºËÐÄ/256K/É¢×° 300 AMD Duron 950 Socket-A/64K/É¢×° 145Duron 1000 Socket-A/64K/É¢×° 170 À×Äñ 900 Socket-A/256K/É¢×° 198À×Äñ 1.3G Socket-A/256K/É¢×° 320 AthlonXP 1600+ Socket-A/256K/É¢×° 370 AthlonXP 1700+ Socket-A/256K/É¢×° 400¶þؼÖ÷°åϵÁУº(µ¥Î»:Ôª) ×êʯAK75-AL VIA KT133A/Socket A/×î¸ßÖ§³Ö133MHz/DMA100/ÄÚ½¨AC97Éù¿¨ 320WT70-EC Intel 850/Socket 423/P4Ö÷»ú°å/Ö§³ÖPC800 RDRAM/DMA100/ÄÚ½¨AC97Éù¿¨ 560NB72-SN Intel 845/Socket 478/P4Ö÷»ú°å/Ö§³Ö SDRAM/DMA100/ÄÚ½¨AC97Éù¿¨ 510»ªË¶ P4T-F Intel 850/ATX/Socket 423/Ö§³Ö400MHzFSB/DMA 100/AGP Pro/Ö§³ÖPentium4 CPU 460P4T-E Intel 850/ATX/Socket 478/Ö§³Ö400MHzFSB/DMA 100/AGP Pro/Ö§³ÖPentium4 CPU 650 P4B Intel I845/Socket478/SDRAM/AC97 560P4S333 SIS645/Socket 478/DDR/CMI8738 6-CH S478 480P4S333-M SIS645/Socket 478/DDR/CMI8738 6-CH S478 440 TUV4X VIA 694T/ATX/Socket 370/Ö§³Ö133MHzFSB/DMA 100/AGP 4X/Ö§³ÖP3¡¢ÈüÑïCPU 290A7 V133-C VIA KT133A/ATX/Socket A/ATA100/AGP 4X 320¼¼¼Î GA-8IDXH INTEL 845оƬ×é/Ö§³Ö478 P4 CPU/AGP4X UDMA100/Ë«BIOSÉè¼Æ/¼¯³É´´ÐÂÉù¿¨ 460GA-8IRX Intel 845оƬ/Socket 478/ÍâƵ×î¸ß400/Ö§³ÖDDRAM/´´ÐÂ5880Éù¿¨ 4308IRXP Intel 845оƬ/Socket 478/ÍâƵ×î¸ß400/RAID/USB2.0/Ö§³ÖDDRAM/´´ÐÂ5880Éù¿¨ 6107ZXH KT133A/Socket A /AC97 /4X AGP /ATA 100/Ö§³Ö¶¾Áú¡¢À×ÄñCPU 2907ZXR KT133оƬ/Socket A/´ø´´ÐÂÉù¿¨/DMA100/RAID 530΢ÐÇ 845 Ultra-AR Intel 845D/ATX/Socket 478/400MHz/ATA-133/AGP 4X/RAID 610845 Ultra Intel 845оƬ/Socket 478/ÍâƵ×î¸ß400/Ö§³ÖDDRAM/AC97Éù¿¨ 460645 PRO SIS645/Socket 478/SDRAM/AC97Éù¿¨ 320815EP-T Intel 815EPT/ATX/Socket 370/Ö§³Ö133MHzÍâƵ/AGP 4X/DMA 100/Ö§³ÖÐÂP3¡¢ÈüÑïCPU 3206309NL 100-A VIA Apollo Pro 133A/ATX/Socket370/×î¸ß138MHzÍâƵ/DMA100/ÄÚÖÃÉù¿¨ 220Éý¼¼ TH7 II Intel I850/Ö§³ÖSOCKET 478µÄP4 CPU/AGP 4X UDMA100/Ö§³ÖRD RAMBUS 610 BWBD7R 845D/Socket478/Ö§³ÖDDR/AC97Éù¿¨/AGP4X/UDMA100/Ö§³Ö4 DIMM/RAID 500 BD7 845D/Socket478/Ö§³ÖDDR/AC97Éù¿¨/AGP4X/UDMA100/Ö§³Ö2 DIMM 400BL7-RAID Intel I845/Ö§³ÖSOCKET478µÄP4 CPU/AGP4X UDMA100/RAID/Ö§³Ö3GB SDRM 410ÈýؼÄÚ´æϵÁУº(µ¥Î»:Ôª) HY128M T-H/168PIN SDRAM/PC133(µ¥Ãæ) 65256M T-H/168PIN SDRAM/PC133 140 128M DDR 184PIN DDR RAM 88256M DDR 184PIN DDR RAM/Ô³§ÄÚ´æ 180 ÈýÐÇ 256M ECC 7.5ns/168PIN SDRAM/ECC/·þÎñÆ÷ÄÚ´æ/Ô³§ÄÚ´æ/PC133 320128M Rambus 184PIN RDRAM/Ô³§ÄÚ´æ/PC800 100256M Rambus 184PIN RDRAM/Ô³§ÄÚ´æ/PC800 210 128M DDR 184PIN DDR SDRAM/Ô³§ÄÚ´æ/2100MHz/CL2.0 98256M DDR 184PIN DDR SDRAM/Ô³§ÄÚ´æ/2100MHz/CL2.0 200 ½ðÊ¿¶ÙKingston KVR133X64C3 256MB/168PIN SDRAM/PC 133 188KVR133X64C3 512MB/168PIN SDRAM/PC 133 460 KVR266X64C25 128MB/184PIN DDR/PC266 110KVR266X64C25 256MB/184PIN DDR/PC266 210 KVR800X16-8 128MB/184PIN RAMBUS/PC800 130 Kingmax 128M 6ns/168PIN SDRAM/PC150 90256M 7ns/168PIN SDRAM/PC-150 180 128M DDR 184PIN DDR RAM 120 256M DDR 256MB DDR RAM/PC2700/ 240 ËÄؼӲÅÌϵÁУº(µ¥Î»:Ôª) IBMÌÚÁúÈý´ú60GXP/60AV 60GB/ATA/100/2MB/7200rpm/IDE 370ÌÚÁúËÄ´ú120GXP/40AVV 40GB/ATA/100/2MB/7200rpm/IDE 320 ÌÚÁúËÄ´ú120GXP/60AVV 60GB/ATA/100/2MB/7200rpm/IDE 380 ÌÚÁúËÄ´ú120GXP/120AVV 120GB/ATA/100/2MB/7200rpm/IDE 1100 UltraSter/DDYST18350 18GB/Ultra 160 /68P/ 160MB/s/4MB/1rpm /SCSI 680UltraSter/DDYST18350 18GB/Ultra 160 /80P/ 160MB/s/4MB/1rpm /SCSI 770 UltraSter/DDYST36950 36GB/Ultra 160 /68P/ 160MB/s/4MB/1rpm /SCSI 1100 UltraSter/DDYST36950 36GB/Ultra 160 /80P/ 160MB/s/4MB/1rpm /SCSI 1300 ×êʯ ÐÇ×êÈý´ú/4D040H2 40GB/UDMA 100/5400rpm/2M/IDE/µ¥µú40GB/ ±£ÈýÄê 300ÐÇ×êÈý´ú/4D060H3 60GB/UDMA 100/5400rpm/2M/IDE/µ¥µú40GB/ ±£ÈýÄê 380 ÐÇ×êÈý´ú/4D080H4 80GB/UDMA 100/5400rpm/2M/IDE/µ¥µú40GB/ ±£ÈýÄê 540 ½ð×êÆß´ú/6L020J/L1 20GB/UDMA 133/7200rpm/2M/IDE/µ¥µú40GB/ ±£ÈýÄê 320 ½ð×êÆß´ú/6L040J/L2 40GB/UDMA 133/7200rpm/2M/IDE/µ¥µú40GB/ ±£ÈýÄê 360 ½ð×êÆß´ú/6L080J/L4 80GB/UDMA 133/7200rpm/2M/IDE/µ¥µú40GB/ ±£ÈýÄê 800Ï£½Ý ¿áÓã¢ôϵÁÐ ST340016A 40GB/Ultra ATA/100/2MB/7200rpm/IDE/3.5´ç/µ¥µú40G 320¿áÓã¢ôϵÁÐ ST360021A 60GB/Ultra ATA/100/2MB/7200rpm/IDE/3.5´ç/µ¥µú40G 360U6 ST320410A 20.4G/Ultra ATA/100/2M/5400rpm/IDE/3.5´ç/µ¥µú40GB 270U6 ST340810A 40.8G/Ultra ATA/100/2M/5400rpm/IDE/3.5´ç/µ¥µú40GB 280 ¿áÓã ST39236LC 9.1GB/Ultra 160/80P/2M/7200rpm/SCSI 570¿áÓã ST336737LW 36.7GB/Ultra 160/68P/2M/7200rpm/SCSI 1200 ¸»Ê¿Í¨ MAN3184MC 18.4GB/Ultra 320 /80P
Re: fakeroot status
On Sun, May 12, 2002 at 05:14:17PM -0400, Roland McGrath wrote:
> > Cool, I started implementing it when I noticed that it isn't too easy to
> > construct the mach_msg call from the inp.
>
> Sure it is.
Well, I will reserve my final judgement for the time when everything works
as it should :)
> > Likewise, I think that the msgh_local_port should be unchanged, so the
> > other server sends the reply directly to the user.
>
> Nope. The fields are swapped on the way through the kernel, so you have to
> swap them back. See rpctrace.
Cruel. So the code in libpager/demux.c is actually wrong in using the
remote part rather than the local port, I take it?
> > I have to think more about the problems that this doesn't solve.
>
> Do you mean the issue of peropen state that I mentioned, or something else?
Yeah, that one.
Ok, here is an update:
* in a fakeroot, running suid/sgid binaries doesn't work, it fails with
Operation not permitted. It seems that auth_makeauth fails:
83->2 ( 82 0 "ids" "PWD=/" { 80 89 35} { 30 54 38 99 91 (null)}
{18 0 0 0 0} pn{135 127 129 92 134 120 119 90 12 75 0 89 91 92}
pn{117}) 67->21013 () = 0 {23 3 0 16297 1019142589 0 35309 1 0 0 6372
1021229047 0 1019142272 0 1019142514 0 8192 16 0 0 135676248 377 135356968
135356968 135356968 361 135357320 135357320 135356968 345 135357304}
38->25000 () = 0 1000 {1000 1000} 1000 {1000 1000}
38->25001 ( 9 0 {1000 0 1000} 1000 {1000 1000}) = 0x4001 (Operation
not permitted)
I am not sure what happens here, but it seems to indicate that the way
programs are executed in a fakeroot is more like if the program comes from
fakeroot itself rather than the underlying filesystem.
* Creating pipe fails also with Operation not permitted, and I have no clue
yet why. /servers/socket/1 is correctly looked up (with flags being 0, by
the way), and then I don't think the pflocal server is even involved in
the matter. I will have to do more debugging here.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: fakeroot status
> Cruel. So the code in libpager/demux.c is actually wrong in using the
> remote part rather than the local port, I take it?
Yes.
> > Do you mean the issue of peropen state that I mentioned, or something else?
>
> Yeah, that one.
Ok, I don't think that will bite for the package-building uses of fakeroot.
> Ok, here is an update:
>
> * in a fakeroot, running suid/sgid binaries doesn't work, it fails with
> Operation not permitted. It seems that auth_makeauth fails:
>
> 83->2 ( 82 0 "ids" "PWD=/" { 80 89 35} { 30 54 38 99 91 (null)}
> {18 0 0 0 0} pn{135 127 129 92 134 120 119 90 12 75 0 89 91 92}
> pn{117}) 67->21013 () = 0 {23 3 0 16297 1019142589 0 35309 1 0 0 6372
> 1021229047 0 1019142272 0 1019142514 0 8192 16 0 0 135676248 377 135356968
> 135356968 135356968 361 135357320 135357320 135356968 345 135357304}
> 38->25000 () = 0 1000 {1000 1000} 1000 {1000 1000}
> 38->25001 ( 9 0 {1000 0 1000} 1000 {1000 1000}) = 0x4001 (Operation
> not permitted)
>
> I am not sure what happens here, but it seems to indicate that the way
> programs are executed in a fakeroot is more like if the program comes from
> fakeroot itself rather than the underlying filesystem.
That makes sense. Indeed, fakeroot is netfs so it exec's by accessing the
underlying node the same way exec'ing on nfs accesses the remote file.
It's fshelp_exec_reauth trying the makeauth call that rightly fails since
fakeroot's auth port is not root.
There are a few different ways to attack this:
1. Override netfs_S_file_exec to just pass it through. Then a setuid exec
will be a real setuid exec and will escape from the fakeroot and
fakeauth universes entirely. This is the behavior of Linux fakeroot,
since it does nothing special for exec and LD_PRELOAD is ignored by
setuid executables.
2. Run fakeroot under fakeauth instead of the other way around.
That is, fakeroot.sh does:
exec /bin/fakeauth /bin/settrans --chroot \
/bin/sh -c "cd `pwd`; exec $*" \
-- / /hurd/fakeroot
That will put fakeroot itself inside the fakeauth universe where
it believes it can do bona fide setuid exec's. However, it will
in fact be getting a new fake auth port that claims to be whatever
IDs the setuid process should have, but is really the fakeauth owner.
The setuid exec will get a faked auth port that claims what it should,
and so will continue in the fakeauth universe. However, since netfs
will set EXEC_SECURE, the exec server will give it the global crdir
and so it will escape the fakeroot universe. (Or we could hack fakeroot
to act like netfs_S_file_exec but clear the EXEC_SECURE flag.)
3. Hack fakeroot to fake setuid/setgid exec in some particular way.
#1 is the easiest and seems appropriate since the point of the exercise is
to approximate the behavior of Linux fakeroot.
> * Creating pipe fails also with Operation not permitted, and I have no clue
> yet why. /servers/socket/1 is correctly looked up (with flags being 0, by
> the way), and then I don't think the pflocal server is even involved in
> the matter. I will have to do more debugging here.
You mean fakeroot is not involved any more, right? The call that matters
is the socket_create call that needs to be forwarded by the generic code in
fakeroot's netfs_demuxer. It's after that call is made that fakeroot
should no longer be involved.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: fakeroot status
On Sun, May 12, 2002 at 07:40:05PM -0400, Roland McGrath wrote: > > * Creating pipe fails also with Operation not permitted, and I have no clue > > yet why. /servers/socket/1 is correctly looked up (with flags being 0, by > > the way), and then I don't think the pflocal server is even involved in > > the matter. I will have to do more debugging here. > > You mean fakeroot is not involved any more, right? The call that matters > is the socket_create call that needs to be forwarded by the generic code in > fakeroot's netfs_demuxer. It's after that call is made that fakeroot > should no longer be involved. Ugh, netfs_attempt_lookup did not fail, but netfs_S_dir_lookup does! This is because it sees that S_ISCHR evaluates to true on the node. Because fakeroot has no translator started on the node yet, fshelp_fetch_root will try to do so. Of course, it is not allowed to start a translator (whatever type of translator it wants to start, I didn't check which, maybe even "chrdev") as root (which is still the owner of /server/socket/1), so fshelp_fetch_root fails with EPERM. Distress. What can we do? Override... netfs_S_dir_lookup? fshelp_fetch_root? Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: fakeroot status
> Ugh, netfs_attempt_lookup did not fail, but netfs_S_dir_lookup does! This > is because it sees that S_ISCHR evaluates to true on the node. Because > fakeroot has no translator started on the node yet, fshelp_fetch_root will > try to do so. I see. This is just a case of not matching the assumptions that netfs was originally written for. netfs_S_dir_lookup is much too complicated a function to want to override with a duplicate version having a slight difference. I think we should just add a hook to netfs to disable its special handling of special files. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
(¼ºÀα¤°í) ÃÖ°ÀÇ ¼ºÀλçÀÌÆ® !!
Title: SexyLove SexyLove ¼¼»ó¿¡¼ °¡Àå ´ÞÄÞÇÑ ¿µÈ°ü Â¥¸´ÇÑ Äè°¨ Â¥¸´ÇÑ À¯È¤ ¿À¸£°¡Áò°ü ¿¢±â½º°ü ¼ºÀÎäÆà À¯¸Ó¹æ ½º¸± ³ÑÄ¡´Â À̹ÌÁö È¥ÀÚ¸¸ÀÇ Áñ°Å¿òÀ» ´À²¸º¸¼¼¿ä... ±ÍÇÏÀÇ Çã¶ô¾øÀÌ È«º¸¼º ÀüÀÚ ¿ìÆíÀ» º¸³»°Ô µÈ Á¡ Á¤ÁßÈ÷ »ç°ú µå¸³´Ï´Ù. Á¤º¸Åë½Å¸Á ÀÌ¿ëÃËÁø¹ý ±ÔÁ¤À» ÁؼöÇÏ¿© ±¤°í¸ÞÀÏÀÓÀ» Ç¥½ÃÇÏ¿´À¸¸ç, ¼ö½Å°ÅºÎ ÀåÄ¡¸¦ ¸¶·ÃÇÏ°í ÀÖ½À´Ï´Ù. ±ÍÇÏÀÇ ÀüÀÚ ¿ìÆí ÁÖ¼Ò´Â ÀÎÅÍ³Ý »óÀÇ °ø°³µÈ Àå¼Ò¿¡¼ ½ÀµæÇÏ¿´À¸¸ç, ÀúÈñ´Â ±ÍÇÏÀÇ ÀüÀÚ¿ìÆí ÁÖ¼Ò¿Ü ¾î¶°ÇÑ °³ÀÎÁ¤º¸µµ °¡Áö°í ÀÖÁö ¾ÊÀ¸¹Ç·Î ¾È½ÉÇϽñ⠹ٶø´Ï´Ù. ¼ö½ÅÀ» ¿øÄ¡ ¾ÊÀ¸½Ã¸é [¼ö½Å°ÅºÎ]¸¦ Ŭ¸¯ÇØ ÁֽʽÿÀ. 19¹Ì¸¸ ´ë»óÀÚ´Â ÃâÀÔÇÒ ¼ö ¾ø½À´Ï´Ù. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: fakeroot status
On Sun, May 12, 2002 at 07:40:05PM -0400, Roland McGrath wrote: > There are a few different ways to attack this: > > 1. Override netfs_S_file_exec to just pass it through. Then a setuid exec >will be a real setuid exec and will escape from the fakeroot and >fakeauth universes entirely. This is the behavior of Linux fakeroot, >since it does nothing special for exec and LD_PRELOAD is ignored by >setuid executables. I put it in. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Norton AntiVirus 在您发送的消息中发现了病毒。受感染附件已被删除。
ÊܸÐȾ¸½¼þµÄÊÕ¼þÈË£ºliushaohua\ÊÕ¼þÏä ÏûÏ¢Ö÷Ì⣺DATAFORMATAS ÒÑɾ³ýÁËÒ»¸ö»ò¶à¸ö¸½¼þ¡£ ÓÉÓÚÏÂÁÐÔÒò£¬¸½¼þ DATAFLD.scr ±»É¾³ý£º ·¢ÏÖ²¡¶¾ W32.Klez.H@mm¡£ msg04526/bin0.bin Description: application/ms-tnef
[광고] bug-hurd님 CD제작&컨텐츠개발&홈페이지제작관련 광고입니다.
Title: main2
(no subject)
Please accept our sincere apology if the e-mail repeats itself due to group-mailing system despite the refusal of receiving of them. ..¾È³çÇϼ¼¿ä? ÇÑ¿ïµðÁöÅØÁÖ½Äȸ»ç(º¸À̽ºÅ©¶ô¼ðÃÑÆÇ)ÀÔ´Ï´Ù . ±Ý¹ø ÀúÈñȸ»ç¿¡¼ "º¸À̽ºÅ©¶ô¼ð"°³¹ß (½Ç¿ë ƯÇã) ÇÏ¿© Àü±¹ Áö¿ªÀûÀ¸·Î ÀÌ»ç¾÷¿¡ ÇÔ²² µ¿ÂüÇÏ½Ç ºÐ( ´ë¸®Á¡ ¹× Áö¿ª ¿µ¾÷ÇϽǺР)À» ¸ð½Ã°í ÀÖ½À´Ï´Ù. ÇöÀç´Â °ñ¸ñ±æÀ̳ª º¸ÇàÀÚ°¡ ¸¹Àº °÷ Áö³¯¶§ Å©¶ô¼ð ´©¸£±â°¡ ¸Å¿ì ºÎ´ã½º·¯¿ü½À´Ï´Ù. º»Á¦Ç°À» Â÷·® º»³×Æ®¼Ó¿¡ ÀåÂøÇÑ ÈÄ ±âÁ¸ ÇÚµéÀÇ Å©¶ô¼ðÀ» »ì¦ Çѹø ´©¸£¸é »ó³É½º·± ¿©ÀÚÀ½¼ºÀ¸·Î "»§»§ ºñÄÑÁÖ¼¼¿ä" ÇÏ´Â ¸àÆ®°¡ ³ª¿À¸ç ¶ÇÇѹø ´©¸£¸é "Á˼ÛÇÕ´Ï´Ù ºñÄÑÁÖ¼¼¿ä"ÇÏ´Â ¸àÆ®°¡ ³ª¿É´Ï´Ù. ¿¬°ÅǪ µÎ¹ø ´©¸£¸é "»§»§ »¡¸® ºñÄÑÁÖ¼¼¿ä" ÇÏ´Â ¸àÆ®°¡ ³ª¿À°Ô µÇ¾î ÀÖ½À´Ï´Ù. (2002³â 2¿ù 24ÀÏ ¿ÀÀü 9½Ã14ºÐ ÄÉÀ̺í TV(YTN NEWS)¹æ¿µ ÂüÁ¶) (2002³â 5¿ù 2ÀÏ SBS 8½Ã NEWS ¹æ¿µÂüÁ¶¶ÇÇÑ Å©¶ô¼ðÀ» ±æ°Ô ´·¯Áֽøé ÀÏ¹Ý ±âÁ¸ Å©¶ô¼ðÀ½ÀÌ ³ª¿É´Ï´Ù. ±×¸®°í ¿µ¾î, ÀϾî, Áß±¹¾îµî ¾î¶² ¾ð¾î·Îµµ °¡´ÉÇϸç,Â÷·® ½Ç³» ¿¡´Â ÀÏüÀÇ ÀåÂøÀÌ ¾øÀ¸¸ç, º»³×Æ® ¼Ó¿¡ ÀåÂøÇÕ´Ï´Ù. º¸ÇàÀÚ°¡ ¸¹Àº°÷ Áö³¯¶§ »ì¦ ´©¸£¸é ¿îÀüÀÚ¿Í º¸ÇàÀÚ°£¿¡ ¼·Î ¿ôÀ¸¸ç ÅëÇà ÇÒ¼ö ÀÖÀ¸¸ç ¸Å¿ì ¹ÝÀÀÀÌ ÁÁ½À´Ï´Ù. ¼Ò¾×À¸·Îµµ ÇöÀçÀÇ ¾÷Á¾°ú °â¾÷, ¶Ç´Â º»¾÷À» ÇÏ½Ç ¼ö ÀÖ½À´Ï´Ù. 1°³ ±¸ÀԽà Åù質 µî±â·Î ÀÔ±ÝÈ®ÀÎÈÄ ¹ß¼ÛÇØ µå¸³´Ï´Ù ÀÔ±Ý °èÁÂ:050-072457-02-018(±â¾÷ÀºÇà) ¿¹±ÝÁÖ: ±Ç¹Ì¶õ ¿¬¶ô Áֽʽÿä. ÇÑ¿ïµðÁöÅØÁÖ½Äȸ»ç(º¸À̽ºÅ©¶ô¼ðÃÑÆÇ)02)698-9658 ,017-304-6625 ¸ÞÀÏÁÖ¼Ò [EMAIL PROTECTED] °¨»çÇÕ´Ï´Ù.ÁÁÀº½Ã°£ µÇ½Ê½Ã¿ä. *ȸ¿ø´Ôµé¿¡°Ô º¸³»´Â Àüü¸ÞÀÏÀ̶ó ¸ÞÀÏÀÌ Áߺ¹µÉ ¼öµµ ÀÖÀ¸´Ï ±× Á¡ ¾çÇعٶø´Ï´Ù*. º» ¸ÞÀÏÀÌ ÀüÇô µµ¿òÀÌ µÇÁö ¾Ê´Â ¸ÞÀÏÀ̾ú´Ù¸é Á¤ÁßÈ÷ »ç°úµå¸®°Ú½À´Ï´Ù. ^^; º» ¸ÞÀÏÀº Á¤º¸Åë½ÅºÎ ±Ç°í »çÇ׿¡ ÀÇ°Å Á¦¸ñ¿¡ [±¤°í]¶ó Ç¥½ÃµÈ ±¤°í ¸ÞÀÏÀÔ´Ï´Ù.¼ö½Å°ÅºÎ ¹öÆ°À» Ŭ¸¯ÇÏ½Ã¸é ¼ö½Å°ÅºÎ󸮰¡ ÀÌ·ç¾î Áý´Ï´Ù. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Bug#146797: hurd: policy violation section 13.2
Package: hurd Version: 20020418-1 Severity: serious Justification: policy violation section 13.2 diff -u /usr/src/hurd-cvs/debian/postinst debian/postinst --- /usr/src/hurd-cvs/debian/postinst Sat Oct 9 00:57:30 1999 +++ debian/postinst Mon May 13 06:56:53 2002 @@ -16,7 +16,7 @@ # Install info files into the dir file. -install-info --quiet --section "Hurd" "The Hurd" /usr/info/hurd.info.gz +install-info --quiet --section "Hurd" "The Hurd" /usr/share/info/hurd.info.gz # Manage alternatives. diff -u /usr/src/hurd-cvs/debian/rules debian/rules --- /usr/src/hurd-cvs/debian/rules Sat Dec 29 12:42:28 2001 +++ debian/rulesMon May 13 06:56:36 2002 @@ -27,7 +27,7 @@ PREFIX = /usr BINDIR = $(PREFIX)/bin MANDIR = $(PREFIX)/man -INFODIR = $(PREFIX)/info +INFODIR = $(PREFIX)/share/info DOCDIR = $(PREFIX)/share/doc/$(package) # Package specific stuff. The idea is to try to make the rules kind regards guillem ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Check out BMII OPTOJ
___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Hurd TWiki trial - Announcement
Thank you to all the people who replied. I had some suggestions from Robert Millan and Oystein Viggen on how to use dyndns.org for hosting a machine myself. Also thanks to Peter Thoeny, TWiki's author for his interest and encouragement. Joachim Nilsson has provided a home for the Hurd TWiki trial on a server in Sweden. Please check out the pages at: http://www.vmlinux.org/twiki/bin/view/Hurd/WebHome If you have some relevant Hurd information on your own web pages, have surfed and found many resources that could use indexing or would like to write some new documentation, this is the place. You are encouraged to create and modify pages as you see fit. This space can be used for semi-private information as well as a central resource for information about the Hurd. During the introduction phase I will assume the role of editor and coordinator. Comments and suggestions are encouraged. Authentication is possible anonymously using the WikiName TWikiGuest (password: guest) or with your own WikiName. Self registration and cration of your own WikiName is available from the TWikiRegistration URL. How people choose to use authentication is left undefined at the moment to adapt to whatever editing norms the Hurd community wishes to establish. http://www.vmlinux.org/twiki/bin/view/TWiki/TWikiRegistration If you want updates about the Hurd TWiki, automatic updates should soon be available by adding your name to the WebNotify page. You should automatically get email after any Hurd page is created or updated. This isn't working just yet, but it should be functional soon. http://www.vmlinux.org/twiki/bin/view/Hurd/WebNotify -- -- Grant Bowman<[EMAIL PROTECTED]> * Grant Bowman <[EMAIL PROTECTED]> [020510 14:38]: > Greetings, > > After some initial discussions with Marcus, I would like to setup and > help administer a TWiki [1] forum for the Hurd project. I am evaluating > options on where to host a trial implementation, perhaps moving the data > to a more centrally hosted resource if the trial proves successful. > Options I am considering right now are Savannah, some willing Internet > host I can find or perhaps even borrowing a section of an existing > TWiki. > > While I am running a TWiki on my machine, my ISP uses DHCP. If there > are any suggestions, please let me know and I can later summarize what I > find for the list. > > Thanks, > > -- > -- Grant Bowman<[EMAIL PROTECTED]> > > [1] http://twiki.org > > > ___ > Bug-hurd mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/bug-hurd > ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: hurd/utils fakeauth.c
Roland McGrath <[EMAIL PROTECTED]> writes: > CVSROOT: /cvsroot/hurd > Module name: hurd > Changes by: Roland McGrath <[EMAIL PROTECTED]> 02/05/12 17:02:13 > > Modified files: > utils : fakeauth.c > > Log message: > 2002-05-12 Roland McGrath <[EMAIL PROTECTED]> > > * fakeauth.c (main): Don't use posix_spawnp. Use _hurd_exec instead. _hurd_exec is a private function...it seems to me that if we want to use it in programs in general, we should export it. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: establishing the callers PID
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: > Right, but that's already a Hurd-specific extension. So it's fine to > expect it to use another Hurd-specific extension to get a reliable PID > or other identification. What would such an extension look like? /Niels ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
½õ³ÌÆÚ¿¯
Title: newsletter óÒ×´óÈ«¡¡©¦¡¡»õÔËÊֲᡡ©¦¡¡Í¨¹ØÖ¸ÄÏ¡¡©¦¡¡ÉÌÂùËÎÊ¡¡©¦¡¡º½Ã³ÂÛ̳ 2002Äê5ÔÂ13ÈÕÐÇÆÚÒ»¡¡µÚ¶þÆÚ ×ð¾´µÄÓû§£º ÄúºÃ£¡ÒÔÏÂÊǽõ³Ì»õÔËÍøΪÄúÁ¿Éí¶¨ÖƵĵڶþÆÚ×ÊѶÀàÓʼþ£¬Çë²ÎÔÄ¡£ »õÔËÊÖ²á>>> ¡¾»ù´¡ÖªÊ¶¡¿¹ú¼Ê»õÎïÔËÊäµÄÐÔÖʺÍÌص㠡¾·¨ÂÉ·¨¹æ¡¿ ÖлªÈËÃñ¹²ºÍ¹ú¹ú¼Êº£ÔËÌõÀý(2002Äê1ÔÂ1ÈÕÆðʵʩ) ¡¾²Ù×÷ʵÎñ¡¿ÍÐÔ˵¥Óë×°Ïäµ¥¶þµ¥ÉÉÖÆÂí»¢²»µÃ ¡¾°¸Àý·ÖÎö¡¿ ÏäÄÚ»õÎï¶ÌÉÙÊÕ»õÈËÎÞȨÏò³ÐÔËÈËË÷ÅâµÄµäÐÍ°¸Àý ¡¾¸Ûº½×ÊÁÏ¡¿ ÊÀ½ç¼°ÎÒ¹úÖ÷Òª¸Û¿Ú óÒ×´óÈ«>>> ¡¾»ù´¡ÖªÊ¶¡¿ ¹ú¼Ê¼¼ÊõóÒײÉÓõķ½Ê½ ¡¾·¨ÂÉ·¨¹æ¡¿ÁªºÏ¹ú¹ú¼Ê»õÎïÏúÊÛºÏͬ¹«Ô¼£¨ÖÐÎİ棩 ¡¾²Ù×÷ʵÎñ¡¿ ³ö¿ÚÐÅ´ûÒµÎñµÄ´û¿î³ÌÐò ¡¾ÉÌÎñ×ÊѶ¡¿ 2002Äê¹ú¼Ê,¹úÄÚÕ¹»áÐÅÏ¢ ¡¾°¸Àý·ÖÎö¡¿ ¡¶¸úµ¥ÐÅÓÃ֤ͳһ¹ßÀý¡·Óë°¸Àý·ÖÎö ¡¾Ã³Ò×͸ÊÓ¡¿ ÖÞ¼ÊÊг¡·ÖÎö--ÑÇÖÞÊг¡ ¡¾ÓйØWTO ¡¿ ÖйúÈëÊÀ·¨ÂÉÎļþ(ÖÐÎÄ°æ) ͨ¹ØÖ¸ÄÏ>>> ¡¾±¨¹ØÒµÎñ¡¿º£¹Ø³ö¿Ú»õÎﱨ¹Øµ¥ÌîÖƹ淶 ¡¾º£¹Ø·¨¹æ¡¿ÖлªÈËÃñ¹²ºÍ¹úº£¹Ø½ø³ö¿ÚÉÌÆ·Ô¤¹éÀàÔÝÐа취 ¡¾º£¹ØË°ÂÊ¡¿ 2002ÄêÉÌÆ·×ۺϷÖÀà±í˰ĿϸÔò ¡¾±¨¹Ø´úÂë¡¿ Õ÷ÃâÐÔÖÊ´úÂë±í ¡¾Í¨¹Ø½éÉÜ¡¿ °Ä´óÀûÑÇ¿Ú°¶Í¨¹ØʵÎñÖ¸ÄÏ ¡¾ÊÀ½çº£¹Ø¡¿ º£¹Ø×ÛºÏÐÂÎÅÍø ¡¾µ¥Î»»»Ëã¡¿ ¶ÈÁ¿ºâµ¥Î»»»Ëã±í ¡ï½õ³Ì¹ú¼Ê»õÔ˹ɷÝÓÐÏÞ¹«Ë¾½ß³ÏΪÄúÌṩ¹ú¼Ê»õÔËÁìÓòµÄ·þÎñ.¡ï Èç¹ûÄúÐèÒª»¥ÁªÍø¼¼ÊõÖ§³Ö»ò¹ú¼ÊÔËÊä·þÎñÇëÁªÏµÎÒÃÇ¡£ ÁªÏµµç»°£º86-411-2528051 µç×ÓÐÅÏ䣺[EMAIL PROTECTED] ÁªÏµÈË£º¼ÍÏÈÉú ÖÐ×ÊÔ´¹«Ë¾http://www.net001.net ÌṩÓòÃûÏÈ×¢²áºó¸¶¿î;Ö÷»úÏÈ¿ªÍ¨ºóÊÕ·Ñ·þÎñ,ÖÐ;¿ÉÍË¿î¡£ÌØ»ÝÍƼö£ºÓòÃû+100MÖ÷»ú²¢¸½ËÍ5¸ö10MÆóÒµÓÊÏ䣬ÿÄêÖ»Ðè350Ôª£¡£¡ ʹÓü«ÐÇÓʼþȺ·¢£¬ÎÞÐëͨ¹ýÓʼþ·þÎñÆ÷£¬Ö±´ï¶Ô·½ÓÊÏ䣬ËٶȾø¶ÔÒ»Á÷£¡ÏÂÔØÍøÖ·£º[ÐÄÁ¬ÐÂ]Çé¸ÐÔÚÏߣ¬¸ü¶àÃâ·ÑµÄ³¬¿áÈí¼þµÈÄãÀ´Ï¡¡ ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
