Re: [PATCH v2 hurd] pci-arbiter: Fix long standing bug with PCI access

on info */ >reg_num = > @@ -592,12 +593,17 @@ get_filemap_region (struct node *node, vm_prot_t prot) >if (err) > goto error; > > + /* WARNING: this rounds up the proxied region to a whole page. > + * This may be a security risk, but is the only way to provid

[PATCH v2 hurd] pci-arbiter: Fix long standing bug with PCI access

urity risk, but is the only way to provide access + * to the final page of the memory region */ + rounded_size = round_page (region->size); + /* Create a new memory object proxy with the required protection */ max_prot = (VM_PROT_READ | VM_PROT_WRITE) & prot; err = vm_region_

Re: [PATCH hurd] pci-arbiter: Fix long standing bug with PCI access

: this rounds up the proxied region to a whole page. > + * This may be a security risk, but is the only way to provide access > + * to all of the memory region. (We assume pci memory is at least page > aligned). */ > + if (region->size % rest) > +rest -= region->siz

[PATCH hurd] pci-arbiter: Fix long standing bug with PCI access

page. + * This may be a security risk, but is the only way to provide access + * to all of the memory region. (We assume pci memory is at least page aligned). */ + if (region->size % rest) +rest -= region->size % rest; + else +rest = 0; + /* Create a new memory object pro

[PATCH v2 0/2 gnumach] Parallel SMP init with early gs access

Hi, These two patches complete smp parallel init by preserving early gs access, and makes the cpus all wake concurrently. Care has been taken so memory is not trampled on by other cpus during startup. Thanks, Damien

[PATCH 2/5 gnumach] smp: Remove early GS access

pu_id_lut, %ebx), %ecx - - /* Access per_cpu area */ - movl%ecx,%eax - movl$PC_SIZE,%ebx - mul %ebx - addl$percpu_array, %eax - - /* Record our cpu number */ - movl%ecx, (PERCPU_CPU_ID)(%eax) - - /* Set up temporary percpu desc

Re: [PATCH v2 gnumach] Expose device(mbinfo) with read access to multiboot raw info

Applied, thanks! Damien Zammit, le dim. 27 oct. 2024 09:28:41 +, a ecrit: > --- > i386/Makefrag.am| 2 ++ > i386/i386at/conf.c | 8 +++ > i386/i386at/mbinfo.c| 49 + > i386/i386at/mbinfo.h| 33 +++ > i3

[PATCH v2 gnumach] Expose device(mbinfo) with read access to multiboot raw info

--- i386/Makefrag.am| 2 ++ i386/i386at/conf.c | 8 +++ i386/i386at/mbinfo.c| 49 + i386/i386at/mbinfo.h| 33 +++ i386/i386at/model_dep.c | 3 +++ 5 files changed, 95 insertions(+) create mode 100644 i386/

Re: [PATCH 3/3] Expose device(mbinfo) with read access to multiboot info

Hello, Damien Zammit, le jeu. 24 oct. 2024 00:11:11 +, a ecrit: > +io_return_t > +mbinforead(dev_t dev, io_req_t ior) > +{ > + int err, count; > + > + /* Check if IO_COUNT is valid */ > + if (ior->io_count != sizeof(struct multiboot_raw_info)) > + return D_INVALID_SIZE; Th

[PATCH 3/3] Expose device(mbinfo) with read access to multiboot info

This adds a new mach device called mbinfo that exposes the multiboot information to userspace. --- i386/Makefrag.am| 2 ++ i386/i386at/conf.c | 8 +++ i386/i386at/mbinfo.c| 53 + i386/i386at/mbinfo.h| 35 ++

Re: Can `hwclock` access /dev/rtc after /dev/rtc is added?

Hello, Zhaoming Luo, le mer. 02 oct. 2024 15:41:54 +0800, a ecrit: > However, the probing work > will only be done when the system-specific pre-defined macro `__linux__` is > defined [2]. > Does that mean `hwclock` will still not be able to access /dev/rtc after /dev/ > rtc is im

Can `hwclock` access /dev/rtc after /dev/rtc is added?

d>. Does that mean `hwclock` will still not be able to access /dev/rtc after /dev/rtc is implemented? [1]: https://github.com/util-linux/util-linux/blob/f1c26f0154ec683065109d776e65e568e3917c79/sys-utils/hwclock-rtc.c#L83-L124 [2]: https://github.com/util-linux/util

Re: [PATCH] hurd: Avoid file_check_access () RPC for access (F_OK)

Applied, thanks! Sergey Bugaev, le jeu. 19 sept. 2024 13:14:39 +0300, a ecrit: > A common use case of access () / faccessat () is checking for file > existence, not any specific access permissions. In that case, we can > avoid doing the file_check_access () RPC; whether the given path h

[PATCH] hurd: Avoid file_check_access () RPC for access (F_OK)

A common use case of access () / faccessat () is checking for file existence, not any specific access permissions. In that case, we can avoid doing the file_check_access () RPC; whether the given path had been successfully resolved to a file is all we need to know to answer. This is prompted by

Re: [PATCH 06/17] kern/syscall_subr.c: Use copyin()/copyout() to access user memory

Sergey Bugaev, le mer. 27 mars 2024 19:18:30 +0300, a ecrit: > It's not always possible to directly access user memory from kernel > mode. While it's in theory a lot more expensive to fetch each character > to be printed separately, mach_print() is only a debugging facil

Re: [PATCH 05/17] gsync: Use copyin()/copyout() to access user memory

Applied, thanks! Sergey Bugaev, le mer. 27 mars 2024 19:18:29 +0300, a ecrit: > Depending on the architecture and setup, it may not be possible to > access user memory directly, for example, due to user mode mappings not > being accessible from kernel mode (x86 SMAP, AArch64 PAN).

[PATCH 05/17] gsync: Use copyin()/copyout() to access user memory

Depending on the architecture and setup, it may not be possible to access user memory directly, for example, due to user mode mappings not being accessible from kernel mode (x86 SMAP, AArch64 PAN). There are dedicated machine-specific copyin()/copyout() routines that know how to access user memory

[PATCH 06/17] kern/syscall_subr.c: Use copyin()/copyout() to access user memory

It's not always possible to directly access user memory from kernel mode. While it's in theory a lot more expensive to fetch each character to be printed separately, mach_print() is only a debugging facility, and it's not supposed to be used for printing large amounts of

Re: [PATCH hurd] Check for file_utimens since that's the correct RPC for changing access/modification times

Applied, thanks! Flavio Cruz, le mer. 14 juin 2023 01:06:30 -0400, a ecrit: > libtrivfs/nfsd/fakeroot can now make the call to the underlying > translators. > --- > configure.ac | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configure.ac b/configure.ac > index 44aa69d7.

[PATCH hurd] Check for file_utimens since that's the correct RPC for changing access/modification times

libtrivfs/nfsd/fakeroot can now make the call to the underlying translators. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 44aa69d7..452fe1fd 100644 --- a/configure.ac +++ b/configure.ac @@ -155,7 +155,7 @@ AC_CHECK_FUNCS(fil

Re: lost ssh access - where is a log?

Hi, Sergey Bugaev wrote: On Tue, Nov 29, 2022 at 7:34 AM Guy-Fleury Iteriteka wrote: There is a thread from bugaev that explain the issue and a partial fix : https://floss.social/@bugaevc/109422269238549581 Well, I guess that's my cue to wave hi to this list :) Welcome back! or citing, sa

Re: lost ssh access - where is a log?

Hi Samuel, Samuel Thibault wrote: See this post: https://toot.aquilenet.fr/@bugaevc@floss.social/109422315762760554 indeed, the mkdir /run/sshd/dev settrans -ac /run/sshd/dev/urandom /hurd/random trick gave me a working ssh, probably unsecure  as Sergey writes, but at least it proves we ha

Re: lost ssh access - where is a log?

Riccardo Mottola, le mer. 30 nov. 2022 21:08:23 +0100, a ecrit: > Hi Samuel, > > Samuel Thibault wrote: > > > It is one year old. > > ? No, it's 2 days old. See the workaround he posted there. > > Sorry, I was somehow misled, I don't know. Not accustomed to microblogging I > gues. > > I see the

Re: lost ssh access - where is a log?

Hi Samuel, Samuel Thibault wrote: It is one year old. ? No, it's 2 days old. See the workaround he posted there. Sorry, I was somehow misled, I don't know. Not accustomed to microblogging I gues. I see the several hacks about accessing /dev/urandom as well as having comments about arc4ran

Re: lost ssh access - where is a log?

Riccardo Mottola, le mer. 30 nov. 2022 18:51:35 +0100, a ecrit: > Guy-Fleury Iteriteka wrote: > > There is a thread from bugaev that explain the issue and a partial fix : > > > > https://floss.social/@bugaevc/109422269238549581 > > It is one year old. ? No, it's 2 days old. See the workaround he

Re: lost ssh access - where is a log?

Hello! Guy-Fleury Iteriteka wrote: There is a thread from bugaev that explain the issue and a partial fix : https://floss.social/@bugaevc/109422269238549581 It is one year old... anyone experiencs my issues? I am puzzled: up to the day before my post, I was able to ssh in and it was a fresh

Re: lost ssh access - where is a log?

Sergey Bugaev, le mar. 29 nov. 2022 16:24:22 +0300, a ecrit: > Fortunately — while this has been a year of my personal hell, of being > mistreated, disrespected, and humiliated — they never sent me to > you-know-where. I spent all the time on a military airdrom near > Moscow. So there's not that mu

Re: lost ssh access - where is a log?

Sergey Bugaev, le mar. 29 nov. 2022 16:36:58 +0300, a ecrit: > On Tue, Nov 29, 2022 at 4:24 PM Sergey Bugaev wrote: > > Well, here's a preliminary patch. Please don't expect it to be any > > good, I must have forgotten all the subtleties of glibc development — > > those that I managed to learn in

Re: lost ssh access - where is a log?

On Tue, Nov 29, 2022 at 4:24 PM Sergey Bugaev wrote: > Well, here's a preliminary patch. Please don't expect it to be any > good, I must have forgotten all the subtleties of glibc development — > those that I managed to learn in the first place — over the year. That > being said, it builds; I have

Re: lost ssh access - where is a log?

On Tue, Nov 29, 2022 at 11:47 AM Samuel Thibault wrote: > Sergey Bugaev, le mar. 29 nov. 2022 09:22:20 +0300, a ecrit: > > Hello everyone! > > > > I am indeed out of the army, alive and in one piece. > > !! \o/ !! > > I have to say I was very worried, I'm glad that you are back in one > piece. Th

Re: lost ssh access - where is a log?

Sergey Bugaev, le mar. 29 nov. 2022 09:22:20 +0300, a ecrit: > On Tue, Nov 29, 2022 at 7:34 AM Guy-Fleury Iteriteka > wrote: > > There is a thread from bugaev that explain the issue and a partial fix : > > > > https://floss.social/@bugaevc/109422269238549581 > > Well, I guess that's my cue to wav

Re: lost ssh access - where is a log?

On Tue, Nov 29, 2022 at 7:34 AM Guy-Fleury Iteriteka wrote: > There is a thread from bugaev that explain the issue and a partial fix : > > https://floss.social/@bugaevc/109422269238549581 Well, I guess that's my cue to wave hi to this list :) Hello everyone! I am indeed out of the army, alive a

Re: lost ssh access - where is a log?

Hi, On November 29, 2022 1:27:00 AM GMT+02:00, Riccardo Mottola wrote: >Hi! > >after some updates and other works, I can no longer ssh into my HURD system. > >I can do a local log-in and I can telnet to it. > >ssh yields: > >$ ssh -Y 192.168.1.154 >Connection reset by 192.168.1.154 port 22 > >I

lost ssh access - where is a log?

Hi! after some updates and other works, I can no longer ssh into my HURD system. I can do a local log-in and I can telnet to it. ssh yields: $ ssh -Y 192.168.1.154 Connection reset by 192.168.1.154 port 22 I do not find any useful log in /var/log ! how can I get a ssh log? Cheers, Riccardo

Re: [PATCH 5/6] enable user access

Luca Dariz, le sam. 05 févr. 2022 18:51:28 +0100, a ecrit: > The pmap module is a bit limited on 64 bit paging, so this should be > refined when we'll be able to use addresses over 4G. > > Signed-off-by: Luca Dariz Applied, thanks! > --- > i386/intel/pmap.c | 4 ++-- > 1 file changed, 2 insert

Re: [PATCH libpciaccess] hurd: Fix clients/nested arbiters' access to i/o ports

to use a legacy_io file in /sys, which they use to poke at ports. I'd say we should better use this kind of approach, so that nested arbiters in containers don't have to be given ioperm() access, and they're allowed just to poke at the ports of their assigned PCI devices. Samuel >

[PATCH libpciaccess] hurd: Fix clients/nested arbiters' access to i/o ports

When we fail to enable io ports via x86 method, this means we are a client/nested arbiter. But we still need to enable io ports that are not in PCI CONF1 range. --- src/hurd_pci.c | 57 ++ 1 file changed, 53 insertions(+), 4 deletions(-) diff --git

[PATCH 5/6] enable user access

The pmap module is a bit limited on 64 bit paging, so this should be refined when we'll be able to use addresses over 4G. Signed-off-by: Luca Dariz --- i386/intel/pmap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/i386/intel/pmap.c b/i386/intel/pmap.c index d0bd3b5d..

[PATCH 5/6] enable user access

The pmap module is a bit limited on 64 bit paging, so this should be refined when we'll be able to use addresses over 4G. Signed-off-by: Luca Dariz --- i386/intel/pmap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/i386/intel/pmap.c b/i386/intel/pmap.c index 91835b30..

Re: getty errors in Debian GNU/Hurd over Thinkpad T410. I can't access to tty

gt; inet (+link) inet6 (+link) /hurd/pci-arbiter /hurd/acpi /hurd/shutdown > /hurd/ > > password crash-kill crash-suspend crash-dump-core crash. > > Creating device nodes: fdln: failed to access 'stdin/0': Not a directory > > ln: failed to access 'stdout/1':

Re: getty errors in Debian GNU/Hurd over Thinkpad T410. I can't access to tty

/shutdown /hurd/ > password crash-kill crash-suspend crash-dump-core crash. > Creating device nodes: fdln: failed to access 'stdin/0': Not a directory > ln: failed to access 'stdout/1': Not a directory > ln: failed to access 'stderr/2': Not a directory >

Re: getty errors in Debian GNU/Hurd over Thinkpad T410. I can't access to tty

device nodes: fdln: failed to access 'stdin/0': Not a directoryln: failed to access 'stdout/1': Not a directoryln: failed to access 'stderr/2': Not a directory fdX stdln: failed to access 'stdin/0': Not a directoryln: failed to access 'stdout/1': Not

Re: getty errors in Debian GNU/Hurd over Thinkpad T410. I can't access to tty

> dpkg-reconfigure hurd It shows many errors *pruebas@debian:~$ sudo dpkg-reconfigure hurd* *[sudo] password for pruebas: Setting up translators: /hurd/exec /hurd/proxy-defpager /hurd/pflocal (+link) inet (+link) inet6 (+link) /hurd/pci-arbiter /hurd/acpi /hurd/shutdown /hurd/password cr

Re: getty errors in Debian GNU/Hurd over Thinkpad T410. I can't access to tty

Almudena Garcia, le mar. 17 août 2021 00:01:21 +0200, a ecrit: > After change to mach console, I report that the getty error is not the cause > of > the keyboard lock. > The getty errors continues appearing, but I can using the keyboard in the tty. That doesn't mean that getty is not an underlyin

Re: getty errors in Debian GNU/Hurd over Thinkpad T410. I can't access to tty

n, and that's where you want to investigate. > > What do I have to search? I only have access via Rescue Mode > > You can disable the hurd console from /etc/default/hurd-console, so that > you can reboot in non-rescue, and run it by hand. > > That said, easiest to debug such

Re: getty errors in Debian GNU/Hurd over Thinkpad T410. I can't access to tty

Almudena Garcia, le lun. 16 août 2021 21:32:38 +0200, a ecrit: > > It rather looks to me like it's the Hurd console which cannot start for some > reason, and that's where you want to investigate. > What do I have to search? I only have access via Rescue Mode You can disable

Re: getty errors in Debian GNU/Hurd over Thinkpad T410. I can't access to tty

> It rather looks to me like it's the Hurd console which cannot start for some reason, and that's where you want to investigate. What do I have to search? I only have access via Rescue Mode El lun, 16 ago 2021 a las 21:30, Samuel Thibault () escribió: > Almudena Garcia, le lun.

Re: getty errors in Debian GNU/Hurd over Thinkpad T410. I can't access to tty

Almudena Garcia, le lun. 16 août 2021 20:52:07 +0200, a ecrit: > After install Debian GNU/Hurd in "compatibility" mode in a Thinkpad T410, I've > found many getty errors which avoid the access to the tty. > > It seems any errors in the paths generation, which generates

Re: Privileged ports to access the arbiter

Joan Lledó, le jeu. 06 mai 2021 20:17:07 +0200, a ecrit: > El 5/5/21 a les 20:22, Samuel Thibault ha escrit: > > Mmm, no, we only need it for the device_open case. We don't need it for > > falling back on using file_name_lookup (_SERVERS_BUS_PCI) > > And do we need write permissions to perform the

Re: Privileged ports to access the arbiter

El 5/5/21 a les 20:22, Samuel Thibault ha escrit: Mmm, no, we only need it for the device_open case. We don't need it for falling back on using file_name_lookup (_SERVERS_BUS_PCI) And do we need write permissions to perform the scan?

Re: Privileged ports to access the arbiter

Joan Lledó, le mer. 05 mai 2021 20:11:00 +0200, a ecrit: > I found a problem there: > > https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/blob/master/src/hurd_pci.c#L526 > > I can't run my nested arbiter as a non-privileged user b/c this line > prevents me to connect to the main arbiter by l

Privileged ports to access the arbiter

Hi, fortunately, after pulling last changes and updating hurd-libs0.3 I solved my problems with the arbiter being killed. Now I got my user clients getting the maps correctly, and wanted to go further and implement memory object proxy nesting and pci-arbiter nesting. I found a problem there:

Re: [PATCH] Explain how to access data returned from dir_readdir

Andrew Eggenberger, le ven. 23 avril 2021 07:12:22 -0500, a ecrit: > I see your point. But this is more about the hurd-specific nature of > dir_readdir than the dirent struct. readdir in glibc returns one dirent at a > time, not something called an array that can’t be reliably treated as one. > Tha

Re: [PATCH] Explain how to access data returned from dir_readdir

Hi Jess, This is a part of POSIX, the only Hurd-specific thing is the use of the > underlying RPC rather than the standard C function. I don’t see why we > should > document things that are universally true rather than Hurd-specific. If you > want to know how to use dirent then go read a POSIX man

Re: [PATCH] Explain how to access data returned from dir_readdir

value returned in `data` is described as an "array of struct > +directs" in fs.defs, typical array access (direct[4], etc.) will only work to > +access the individual dirents in `data` if they all happen to be the size of > +struct direct (an alias of struct dirent in glibc). This

[PATCH] Explain how to access data returned from dir_readdir

than the index of the last entry, then 0 is returned in `amount`. If `bufsize` is nonzero, never return more than `bufsize` bytes of data regardless. + +Although the value returned in `data` is described as an "array of struct +directs" in fs.defs, typical array access (direct[4], etc.)

[PATCH] New access method: Hurd via RPCs

From: Joan Lledó A new module for the Hurd that accesses PCI bus using available RPCs. All references to the Hurd in the i386 access method have been removed. --- lib/Makefile | 7 +- lib/configure | 4 +- lib/hurd.c | 381

Re: [PATCH] New access method: Hurd via RPCs

Hello, Joan Lledó, le mar. 16 janv. 2018 12:54:29 +0100, a ecrit: > All references to the Hurd in the i386 access method have been removed. Well, we don't want to remove it entirely, otherwise we'd have a "flag day" for switching between x86 access and pci arbiter acc

[PATCH] New access method: Hurd via RPCs

A new module for the Hurd that accesses PCI bus using available RPCs. All references to the Hurd in the i386 access method have been removed. --- lib/Makefile | 7 +- lib/configure | 6 +- lib/hurd.c | 366 + lib/i386-io

[PATCH] New access method: Hurd via RPCs

A new module for the Hurd that accesses PCI bus using available RPCs. All references to the Hurd in the i386 access method have been removed. --- lib/Makefile | 7 +- lib/configure | 6 +- lib/hurd.c | 366 + lib/i386-io

axxxp - a field access profiler

Hi :) I'd like to share a neat hack with you. It is a field access profiler that can be used on any program written in C (well, in theory at least). I wrote it so that I can use it on gnumach. I used it to come up with 322fa73afed84fe37fb7bfe0583109ff33eb26d7. http://darnassus.scee

Re: [PATCH 3/4] device/chario.c: qualify pointers that access their dereferenced values under locks with __restrict__

On 18.12.2013 00:17:38, Richard Braun wrote: > On Tue, Dec 17, 2013 at 03:58:27PM +0100, Marin Ramesa wrote: > > Qualifier __restrict__ means that only the pointer under > > __restrict__ will be used to access dereferenced values. So if a > > code is under locks and no func

Re: [PATCH 3/4] device/chario.c: qualify pointers that access their dereferenced values under locks with __restrict__

On Tue, Dec 17, 2013 at 03:58:27PM +0100, Marin Ramesa wrote: > Qualifier __restrict__ means that only the pointer under __restrict__ will be > used > to access dereferenced values. So if a code is under locks and no function is > called > in the critical section with pointer

Re: [PATCH 3/4] device/chario.c: qualify pointers that access their dereferenced values under locks with __restrict__

On Tue, Dec 17, 2013 at 06:51:49PM +0100, Samuel Thibault wrote: > I don't think we benefit very much here, do we? restrict is a very > difficult thing to maintain, few programmers really understand what it > means, I'd rather avoid introducing too many of them. I agree. Note that GNU Mach is bui

Re: [PATCH 3/4] device/chario.c: qualify pointers that access their dereferenced values under locks with __restrict__

Marin Ramesa, le Tue 17 Dec 2013 15:58:27 +0100, a écrit : > Qualifier __restrict__ means that only the pointer under __restrict__ will be > used > to access dereferenced values. Yes. > So if a code is under locks and no function is called > in the critical section with pointer

[PATCH 3/4] device/chario.c: qualify pointers that access their dereferenced values under locks with __restrict__

Qualifier __restrict__ means that only the pointer under __restrict__ will be used to access dereferenced values. So if a code is under locks and no function is called in the critical section with pointer as an argument, it's safe to use __restrict__. This allows the compiler to

Re: connect() access bytes after socket address

Could be. I need to see the full patch changing all the cases to give a real opinion about the details.

Re: connect() access bytes after socket address

Samuel Thibault, le Fri 01 Mar 2013 19:17:56 +0100, a écrit : > Roland McGrath, le Fri 01 Mar 2013 09:57:11 -0800, a écrit : > > > I didn't bother, but I can indeed, probably to > > > glibc/include/sys/socket.h, or some other file? > > > > It's only needed for Hurd, so but it in some non-installed

Re: connect() access bytes after socket address

Roland McGrath, le Fri 01 Mar 2013 09:57:11 -0800, a écrit : > > I didn't bother, but I can indeed, probably to > > glibc/include/sys/socket.h, or some other file? > > It's only needed for Hurd, so but it in some non-installed Hurd-only header. So for instance: #define _hurd_sun_path_dupa(__addr

Re: connect() access bytes after socket address

> I didn't bother, but I can indeed, probably to > glibc/include/sys/socket.h, or some other file? It's only needed for Hurd, so but it in some non-installed Hurd-only header. > > (or perhaps it needs to be macro declaring a local VLA) > > I rather used strndupa, provided by glibc/include/string

Re: connect() access bytes after socket address

Roland McGrath, le Fri 01 Mar 2013 09:39:17 -0800, a écrit : > > I agree. I've worked on a patch, pushed to topgit for later submission. > > I hope you did it by adding a common helper function I didn't bother, but I can indeed, probably to glibc/include/sys/socket.h, or some other file? > (or p

Re: connect() access bytes after socket address

> I agree. I've worked on a patch, pushed to topgit for later submission. I hope you did it by adding a common helper function (or perhaps it needs to be macro declaring a local VLA) for at least the cases other than bind. bind needs to be a little different since it needs to do a split, but still

Re: connect() access bytes after socket address

Tanaka Akira, le Thu 28 Feb 2013 15:35:07 +0900, a écrit : > 2013/2/28 Roland McGrath : > > I agree they should be consistent. Note that sendto and sendmsg are > > consistent with connect, rather than with bind. > > I didn't know that. > But I still think that the bind() behavior is better. > >

Re: connect() access bytes after socket address

2013/2/28 Roland McGrath : > I agree they should be consistent. Note that sendto and sendmsg are > consistent with connect, rather than with bind. I didn't know that. But I still think that the bind() behavior is better. Giving the length without NUL is traditional practice in applications. Chan

Re: connect() access bytes after socket address

I agree they should be consistent. Note that sendto and sendmsg are consistent with connect, rather than with bind.

connect() access bytes after socket address

Hi. I found that connect() access bytes after socket address. The test program below specifies a same struct sockaddr_un for bind() and connect(). I expect connect() success but "connect: No such file or directory" error occured. rpctrace shows that bind() binds a socket as the socke

Re: Git write access for Guillem?

Guillem Jover, le Wed 31 Aug 2011 14:28:02 +0200, a écrit : > Something though that would help in the review process would be to add > an explanation of why the change was done (like in normal git commit > messages), which sometimes does not fit in the Subject. It can usually be added as plain tex

Re: Git write access for Guillem?

Hi! On Wed, 2011-08-31 at 12:53:56 +0200, Samuel Thibault wrote: > Thomas Schwinge, le Wed 31 Aug 2011 12:49:40 +0200, a écrit : > > Samuel has recently applied (thanks!) a ton of patches by/for Guillem > > (thanks!); I'd be happy to allow Guillem to do the Git pushes himself > > (after posting th

Re: Git write access for Guillem?

Thomas Schwinge, le Wed 31 Aug 2011 12:49:40 +0200, a écrit : > Samuel has recently applied (thanks!) a ton of patches by/for Guillem > (thanks!); I'd be happy to allow Guillem to do the Git pushes himself > (after posting the patches on bug-hurd and getting them acknowledged). > Any comments? (Or

Git write access for Guillem?

Hi! Samuel has recently applied (thanks!) a ton of patches by/for Guillem (thanks!); I'd be happy to allow Guillem to do the Git pushes himself (after posting the patches on bug-hurd and getting them acknowledged). Any comments? (Or, Samuel, do you have any special/automated/time-saving process f

[bug #28383] Supplementary groups aren't use by access()

Update of bug #28383 (project hurd): Status:None => Wont Fix Reproducibility:None => Every Time Summary: Non-compliant access behavior? => Supplementary groups aren't

Re: Non-compliant access behavior?

J de Boyne Pollard, le Thu 24 Dec 2009 21:24:36 -0800, a écrit : > ST> Then please tell that to gcc people, not me.   > ST> Then please tell that to gcc people, not me. > > *You* are the one *with* the problem. You are the appropriate person > to talk to the gcc maintainers about *your* problem w

Re: Non-compliant access behavior?

ST> But compliancy is also about the common behavior, ST> and here gcc assumes some behavior of access(). Wrong again. The problems with access() and what one should do instead of using access(), have been hashed out some 15 years since. These include what one should do in order to be pr

Re: Non-compliant access behavior?

J de Boyne Pollard, le Thu 24 Dec 2009 09:51:01 -0800, a écrit : > ST> The problem I encountered is that I couldn't run gcc over > ST> files in a directory which belonged to a group my I was in. > ST> I hope you'll too find it quite surprising.   > > Only in

Re: Non-compliant access behavior?

sing.   Only inasmuch as gcc is even using access(), whose use is only really appropriate in the context of set-UID or set-GID executables, and even then is a security hole generation tool. Since when was your compiler set-UID/set-GID? ST> Be it POSIX-compliancy or not, I believe following ST>

Re: Non-compliant access behavior?

J de Boyne Pollard, le Wed 23 Dec 2009 12:41:30 -0800, a écrit : > ST> Apparently access() restricts itself to the real gid, without > ST> including supplementary group IDs. > > As IEEE 1003.1:2004 says, at least by omission, it should. There's no > mention of supp

Re: Non-compliant access behavior?

ST> Apparently access() restricts itself to the real gid, without ST> including supplementary group IDs. As IEEE 1003.1:2004 says, at least by omission, it should. There's no mention of supplementary group IDs in the definition of the access() call. This isn't a particularl

[bug #28383] Non-compliant access behavior?

URL: <http://savannah.gnu.org/bugs/?28383> Summary: Non-compliant access behavior? Project: The GNU Hurd Submitted by: sthibaul Submitted on: mer 23 déc 2009 01:10:51 CET Category: None Sever

Re: access(), test and scripts

> > because in fshelp_access(), as soon as user->uids contains 0, everything > > is permitted, thus making access() always return X_OK... That's wrong. It should always have been (st_mode & 0111) for root.

Re: access(), test and scripts

# ls -l foo > -rw-r--r-- 1 root root 0 May 24 21:31 foo > # [ -x foo ] && echo erf > erf > # ./foo > -bash: ./foo: Permission denied > > because in fshelp_access(), as soon as user->uids contains 0, everything > is permitted, thus making access() always retu

access(), test and scripts

-bash: ./foo: Permission denied because in fshelp_access(), as soon as user->uids contains 0, everything is permitted, thus making access() always return X_OK... What POSIX says is `New implementations are discouraged from returning X_OK unless at least one execution permission bit is set.&

[bug #17651] pci config space access from userspace

Update of bug #17651 (project hurd): Depends on: => task #7840 ___ Reply to this item at: ___ Messa

Re: Problems with Hurd on Mach on Xen: disk access

Thomas Schwinge, le Sat 13 Oct 2007 14:36:20 +0200, a écrit : > Assertion `copy->size <= PAGE_SIZE' failed in file "xen/block.c", line 457 > panic: Debugger invoked, but there isn't one! Non-page aligned more-than-a-page writes i/o are not supported yet, see the comment: "Should probably be enough

Problems with Hurd on Mach on Xen: disk access

" vif = [ 'mac=00:16:3e:ff:42:23' ] ramdisk = "/boot/hurd-modules" hostname = "gnuzifer" #v- #v+ --- Logical volume --- LV Name /dev/sledgehammer/gnuzifer-root VG Namesledgehammer LV UUID89x0au-ssoD-ag3k-oxj9-sRaJ-f

Whence Hurd (was: What is ``access (NULL, whatever)'' supposed to do?)

Hello! On Thu, Apr 12, 2007 at 01:49:55PM -0700, Roland McGrath wrote: > I think tb has covered the essence here already. tschwinge, your comments > here are really not apropos, and frankly they seem gratuitously hostile to > the basic principles that have always driven Hurd development. I apolo

Re: My proposal for `PATH_MAX' and friends (was: What is ``access (NULL, whatever)'' supposed to do?)

I appreciate the intent of your suggestion, but I don't think it can actually meet its goals. I don't think that defining PATH_MAX invalidly will actually be a net gain at all. If defined, PATH_MAX must be a constant. If you have a plan and you cannot compile: static char name[PATH_MAX]

Re: What is ``access (NULL, whatever)'' supposed to do?

I think tb has covered the essence here already. tschwinge, your comments here are really not apropos, and frankly they seem gratuitously hostile to the basic principles that have always driven Hurd development. I really do appreciate your frustrations. We've felt them for a very long time too.

Re: My proposal for `PATH_MAX' and friends (was: What is ``access (NULL, whatever)'' supposed to do?)

At Wed, 11 Apr 2007 10:56:18 +0200, Neal H. Walfield wrote: > > At Tue, 10 Apr 2007 22:10:01 -0700, > Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > > > [1 ] > > On Tue, 2007-04-10 at 21:44 +0200, Thomas Schwinge wrote: > > > Hello! > > > > > > We're still being again and again annoyed by p

Re: My proposal for `PATH_MAX' and friends (was: What is ``access (NULL, whatever)'' supposed to do?)

Hi, On Wed, Apr 11, 2007 at 10:56:18AM +0200, Neal H. Walfield wrote: > Legacy compatibility has always ruled the day. Standards compatibility, not bug compatibility... -antrik- ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman

Re: My proposal for `PATH_MAX' and friends (was: What is ``access (NULL, whatever)'' supposed to do?)

At Tue, 10 Apr 2007 22:10:01 -0700, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > [1 ] > On Tue, 2007-04-10 at 21:44 +0200, Thomas Schwinge wrote: > > Hello! > > > > We're still being again and again annoyed by programs that use `PATH_MAX' > > unconditionally. > > Why stop with this one?

  1   2   3   >