Re: [OE-core] [PATCH 2/6] test-openat: Consider device as well as inode number

2021-09-09 Thread Seebs
On Thu, 9 Sep 2021 16:36:10 +0100 Richard Purdie wrote: > It just so happens that my /home/mac and /home directories have the > same inode number but on different filesystems. Nice catch! -s -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online

Re: [OE-core] [PATCH 3/6] pseudo_client: Do not pass null argument to pseudo_diag()

2021-09-09 Thread Seebs
On Thu, 9 Sep 2021 16:36:11 +0100 Richard Purdie wrote: > pseudo_client.c:848:17: warning: ‘%s’ directive argument is null > [-Wformat-overflow=] 848 | pseudo_diag("couldn't > allocate absolute path for '%s'.\n", I'm sort of curious as to whether pseudo_root_path is ever

Re: [OE-core] [PATCH 5/6] pseudo_client: Make msg static in pseudo_op_client

2021-09-09 Thread Seebs
On Thu, 9 Sep 2021 16:36:13 +0100 Richard Purdie wrote: > - pseudo_msg_t msg = { .type = PSEUDO_MSG_OP }; > + static pseudo_msg_t msg; > + msg = (pseudo_msg_t) { .type = PSEUDO_MSG_OP }; Looks good to me. I'm honestly sort of stunned that the return of the local variable's address

Re: [OE-core] pseudo: Outdated records for newly-ignored paths in database cause mismatches

2021-08-09 Thread Seebs
On Mon, 9 Aug 2021 13:19:51 +0100 "Mike Crowe via lists.openembedded.org" wrote: > Cleaning the work directory makes the problem go away because that > deletes the pseudo databases. > > Does the above make sense as an explanation for these errors? If so, > is there a good way to avoid these

Re: [OE-core] [PATCH pseudo 4/4] Do not return address of local variable - unverified

2021-07-29 Thread Seebs
On Thu, 29 Jul 2021 14:37:28 +0200 "Damian Wrobel" wrote: > the PSEUDO_MSG_OP is being unconditionally assigned to the msg.type > before any real usage of the 'msg' structure. So, if I'm not mistaken > that code was already tested and didn't work well and was reverted > here[1]. I don't think

Re: [OE-core] [PATCH pseudo 4/4] Do not return address of local variable

2021-07-28 Thread Seebs
On Wed, 28 Jul 2021 13:49:17 -0700 Andre McCurdy wrote: > If the caller only cares about yes/no then how about returning 1/0 > instead of a pointer? Other callers are actually using the response, because the pseudo_msg_t* returned from this is how, say, OP_STAT responds with the stat

Re: [OE-core] [PATCH pseudo 4/4] Do not return address of local variable

2021-07-28 Thread Seebs
On Wed, 28 Jul 2021 11:36:22 +0200 "Damian Wrobel" wrote: > Do I correctly assume that pseudo_client_op() has to be fully > reentrant? No. It's never been even a tiny bit reentrant. We used to do the allocate and free thing, and it was incredibly expensive, and the nature of the thing requires

Re: [OE-core] [PATCH pseudo 4/4] Do not return address of local variable

2021-07-27 Thread Seebs
On Tue, 27 Jul 2021 18:30:33 +0200 Damian Wrobel wrote: > The returned pointer has to be freed by the caller not by the callee > function itself. So, this predates the public release, but long ago, that was indeed how it worked, and then LONG ago it was changed so that the pseudo_ipc stuff

Re: [OE-core] [PATCH pseudo 1/4] Remove -fno-strict-aliasing and -Wno-deprecated-declarations

2021-07-27 Thread Seebs
On Tue, 27 Jul 2021 18:35:50 +0200 "Damian Wrobel" wrote: > Based on my experience, It's usually better to see this warning and > fix the code instead of relying on the back magic. Yes, but in the case of the strict aliasing stuff and function pointer stuff, we really, really, *can't* not rely

Re: [OE-core] [PATCH pseudo 1/4] Remove -fno-strict-aliasing and -Wno-deprecated-declarations

2021-07-27 Thread Seebs
On Tue, 27 Jul 2021 13:49:03 +0200 "Damian Wrobel" wrote: > -# no-strict-aliasing is needed for the function pointer trickery. > pseudo_wrappers.o: $(GUTS) pseudo_wrappers.c pseudo_wrapfuncs.c > pseudo_wrapfuncs.h pseudo_tables.h > - $(CC) -fno-strict-aliasing $(CFLAGS) $(CFLAGS_PSEUDO) >

Re: [OE-core] [PATCH pseudo 2/4] Do not pass null argument to pseudo_diag()

2021-07-27 Thread Seebs
On Tue, 27 Jul 2021 13:49:04 +0200 "Damian Wrobel" wrote: > pseudo_diag("couldn't allocate absolute path for > '%s'.\n", > - path); > + path ? path : "null"); Is there any actual code path where pseudo_root_path gets called on a null path? I

Re: [OE-core] [PATCH pseudo 4/4] Do not return address of local variable

2021-07-27 Thread Seebs
On Tue, 27 Jul 2021 13:49:06 +0200 "Damian Wrobel" wrote: > Fixes the following warning: > pseudo_client.c: In function ‘pseudo_client_op’: > cc1: warning: function may return address of local variable > [-Wreturn-local-addr] pseudo_client.c:1592:22: note: declared here >1592 |

Re: [OE-core] [PATCH][pseudo 4/7] Fix some memory leaks

2021-01-08 Thread Seebs
For reference, I believe the rationale on these originally was "none of these functions happen repeatedly, in general, and the extra complexity and potential to get the logic wrong isn't appealing", but I don't think I object to these. -s -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages

Re: [OE-core] [PATCH 2/4] pseudo: Ignore mismatched inodes from the db

2020-09-29 Thread Seebs
On Mon, 28 Sep 2020 22:42:18 +0100 "Richard Purdie" wrote: > It helps to know that! I wasn't sure if you'd hate the path filtering. It was on my to-do list at one point to be able to denote "the pseudo filesystem" in some way and just politely ignore everything outside it. And, possibly, switch

Re: [OE-core] [PATCH 2/4] pseudo: Ignore mismatched inodes from the db

2020-09-28 Thread Seebs
On Mon, 28 Sep 2020 15:51:53 +0100 "Richard Purdie" wrote: > I understand. I have strong evidence that the current handling of such > a case does the wrong thing though as copying the data from the > original inode leads to pretty bad corruption in its own right. Yes. But if you had to choose

Re: [OE-core] [PATCH 2/4] pseudo: Ignore mismatched inodes from the db

2020-09-28 Thread Seebs
On Mon, 28 Sep 2020 14:38:01 +0100 "Richard Purdie" wrote: > This can happen when files are deleted outside of pseudo context and > the inode is reused by a new file which pseduo then "sees". I'm just going to say again: The **ENTIRE REASON** pseudo exists to replace fakeroot is that fakeroot

Re: [OE-core] [PATCH] pseudo: Remove mismatched inodes from the db

2020-09-22 Thread Seebs
On Tue, 22 Sep 2020 18:22:18 +0100 "Richard Purdie" wrote: > The "fun" here is that "make install" is rewriting Makefiles within > the source code tree. The install step runs under pseudo, earlier > ones do not. > If we rerun earlier non-pseudo steps, the Makefiles get reset to their > original

Re: [OE-core] [PATCH] pseudo: Remove mismatched inodes from the db

2020-09-22 Thread Seebs
On Tue, 22 Sep 2020 14:18:24 +0100 "Richard Purdie" wrote: > This can happen when files are deleted outside of pseudo context and > the inode is reused by a new file which pseduo then "sees". In terms of the original design: This would be considered a usage bug, and pseudo issues diagnostics

Re: [OE-core] [pseudo][PATCH 1/2] xattr: Fixed corrupting UID when running setfacl -m on a directory

2020-06-26 Thread Seebs
t; hence influence its development. > > Hope that is ok with you seebs! Seems reasonable to me. SOME DAY I will have free time. :P -s -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#140031): https://lists.openembedded.org/g/openembedded-core/me

Re: [OE-core] [pseudo][PATCH 1/2] xattr: Fixed corrupting UID when running setfacl -m on a directory

2020-06-26 Thread Seebs
On Fri, 26 Jun 2020 16:56:48 +0200 "Johannes Beisswenger" wrote: > The OP_CREATE/REPLACE/SET_XATTR operations in pseudo_op() don't use > msg_header.mode at all, it is only used for DB sanity checks, which > in turn only use the non-permission bits. Right, the relevant part is the immediately

Re: [OE-core] [pseudo][PATCH 1/2] xattr: Fixed corrupting UID when running setfacl -m on a directory

2020-06-26 Thread Seebs
On Fri, 26 Jun 2020 11:40:31 +0200 "Johannes Beisswenger" wrote: > The file mode was accidentally overwritten with only the permission > bits, causing the server to falsely assume that the database was > corrupted (because the msg_header.mode did not contain S_IFDIR > anymore) even though it was

Re: [OE-core] [pseudo][PATCH] pseudo_ipc.h: Fix enum typedef

2020-05-08 Thread Seebs
On Fri, 8 May 2020 08:09:58 +0200 Jacob Kroon wrote: > Hi Peter, > > On 5/3/20 6:26 PM, Seebs wrote: > > On Sun, 3 May 2020 17:49:09 +0200 > > "Jacob Kroon" wrote: > > > >> The type has never been used, so an alternative fix would be to get >

Re: [OE-core] [pseudo][PATCH] pseudo_ipc.h: Fix enum typedef

2020-05-03 Thread Seebs
On Sun, 3 May 2020 17:49:09 +0200 "Jacob Kroon" wrote: > The type has never been used, so an alternative fix would be to get > rid of it altogether, and just keep the enum identifiers. I think I anticipated the type being used for something but it did indeed not happen. It could also just be

Re: [OE-core] [pseudo][PATCH] pseudo_ipc.h: Fix enum typedef

2020-05-02 Thread Seebs
On Sun, 3 May 2020 06:27:12 +0200 "Jacob Kroon" wrote: > 'pseudo_access_t' is a type, so use typedef. > > Fixes building pseudo with gcc 10 where -fno-common is the default. Wow! That's amazing, and yes, that's a bug, and the fix looks right to me. I don't know how that got missed all these

Re: [OE-core] [PATCH] pseudo: add macro guard for seccomp

2020-04-27 Thread Seebs
On Mon, 27 Apr 2020 14:04:16 +0800 "kai" wrote: > | ports/linux/pseudo_wrappers.c:129:14: error: > ‘SECCOMP_SET_MODE_FILTER’ undeclared (first use in this function) > |if (cmd == SECCOMP_SET_MODE_FILTER) { Should the test be against this being #defined, rather than the separate

Re: [OE-core] [pseudo][PATCH] pseudo_util.c: Open file with O_CLOEXEC to avoid fd leak

2020-04-09 Thread Seebs
On Thu, 9 Apr 2020 06:30:37 + "Yu, Mingli" wrote: > We are trying to fix the issue as > http://bugzilla.yoctoproject.org/show_bug.cgi?id=13311 stated. Hmm. I think there's a more subtle logic bug here, and also one of the diagnostics there is a debug message I didn't notice when I made the

Re: [OE-core] [pseudo][PATCH] pseudo_util.c: Open file with O_CLOEXEC to avoid fd leak

2020-04-08 Thread Seebs
On Thu, 9 Apr 2020 10:38:41 +0800 "Yu, Mingli" wrote: > - fd = open(pseudo_path, O_WRONLY | O_APPEND | O_CREAT, 0644); > + fd = open(pseudo_path, O_WRONLY | O_APPEND | O_CREAT | > O_CLOEXEC, 0644); I'm not confident in this. This code is shared between the pseudo client and the pseudo

Re: [OE-core] [PATCH] pseudo: Force seccomp to return success when in fact doing nothing

2020-04-04 Thread Seebs
On Sat, 4 Apr 2020 14:32:03 -0700 "Andre McCurdy" wrote: > Also, since prctl() is Linux specific, it looks like this patch will > make pseudo Linux specific. Is that OK? If so maybe worth making an > official statement that OE is only supported for Linux hosts? We have existing hooks for making

Re: [OE-core] [PATCH 13/25] pseudo: adjust for attr 2.4.48

2019-12-18 Thread Seebs
On Wed, 18 Dec 2019 17:24:21 +0100 Alexander Kanavin wrote: > You can also supply your own definition of ENOATTR, as it doesn't > change. That way lies EVEN MORE madness. I don't have any guarantee that it won't be changed at some point, and... I mean, silly though it sounds to talk about

Re: [OE-core] [PATCH 13/25] pseudo: adjust for attr 2.4.48

2019-12-18 Thread Seebs
On Wed, 18 Dec 2019 17:15:34 +0100 Alexander Kanavin wrote: > On Wed, 18 Dec 2019 at 16:27, Seebs wrote: > > > On Wed, 18 Dec 2019 15:37:46 +0100 > > Alexander Kanavin wrote: > > > > > +Latest versions of attr have removed the xattr.h header, > > >

Re: [OE-core] [PATCH 13/25] pseudo: adjust for attr 2.4.48

2019-12-18 Thread Seebs
On Wed, 18 Dec 2019 15:37:46 +0100 Alexander Kanavin wrote: > +Latest versions of attr have removed the xattr.h header, > +with the rationale that libc is providing the same wrappers. I'm a bit concerned about this -- will this still work with *older* versions of xattr? -s --

Re: [OE-core] [PATCH] pseudo: Drop static linking to sqlite3

2019-11-11 Thread Seebs
On Mon, 11 Nov 2019 08:17:30 -0600 Mark Hatle wrote: > First (early) version of pseudo would fork for the server, there > wasn't a seperate executed server and we had all sorts of problems > with dynamic libraries being loaded and loaded from the correct paths > (due to the LD_PRELOAD). > >

Re: [OE-core] [PATCH] pseudo: Drop static linking to sqlite3

2019-11-09 Thread Seebs
On Sat, 09 Nov 2019 16:30:41 + Richard Purdie wrote: > I did talk briefly to Mark (also cc'd) as he wrote the original patch > and he thought it was possibly because the client was also linking > against sqlite3 and due to the other things the client does, that was > problematic. It

Re: [OE-core] [PATCH] pseudo: Drop static linking to sqlite3

2019-11-09 Thread Seebs
On Sat, 9 Nov 2019 15:35:59 + Richard Purdie wrote: > Back in 2010[1] we made pseudo statically link against sqlite3. Since > then the world has changed, pseudo now has separate processes for the > database in the server and the client and they have separate linking > commands. I'm not

Re: [OE-core] [PATCH] pseudo: Add statx support to fix fedora30 issues

2019-11-07 Thread Seebs
On Thu, 7 Nov 2019 20:04:44 + Richard Purdie wrote: > Modern distros (e.g. fedora30) are starting to use the new statx() > syscall through the newly exposed glibc wrapper function in software > like coreutils (e.g. the ls command). Add support to intercept this > to pseudo. I think this

Re: [OE-core] [PATCH v2] pseudo: Upgrade to latest to fix openat() with a directory symlink [NAK]

2019-08-03 Thread Seebs
On Sat, 3 Aug 2019 05:33:46 -0700 Khem Raj wrote: > Will this fix the file ownership issue that we see with Glibc-locale > packages from time to time? I have no idea. Since I haven't got a reliable reproducer for it, I can't test it in a sane way. -s --

Re: [OE-core] [PATCH v2] pseudo: Upgrade to latest to fix openat() with a directory symlink [NAK]

2019-08-02 Thread Seebs
On Fri, 2 Aug 2019 12:07:33 -0500 Seebs wrote: > Note that there's no lstat, and no AT_SYMLINK_NOFOLLOW. Which is to > say, these stats will be following the symlink even though O_NOFOLLOW > was set. I can probably patch this in a bit. Followup: Patch applied to master, but also in

Re: [OE-core] [PATCH v2] pseudo: Upgrade to latest to fix openat() with a directory symlink [NAK]

2019-08-02 Thread Seebs
On Fri, 2 Aug 2019 11:27:45 -0500 Jason Wessel wrote: > The sequence of openat() followed by an fstat() on the opened file > handle, will erase the pseudo uid entry for the symlink, as shown by > the following lstat() in test 5. The culprit appears to be the > fstat(), but it could be something

Re: [OE-core] [PATCH v2] pseudo: Upgrade to latest to fix openat() with a directory symlink [NAK]

2019-08-01 Thread Seebs
On Thu, 1 Aug 2019 16:37:26 -0500 Jason Wessel wrote: > It seems to have caused really odd problems with the oe link > management that were not there previously, such as: > > > WARNING: pinentry-1.1.0-r0 do_package_qa: QA Issue: > pinentry: /usr/bin/pinentry is owned by uid 5002, which is the

Re: [OE-core] [PATCH] pseudo: Upgrade to latest to fix openat() with a directory symlink

2019-08-01 Thread Seebs
On Thu, 1 Aug 2019 10:55:45 -0700 Jason Wessel wrote: > Many thanks to Peter Seebach for fixing the problem in the pseudo code > to use the same logic which was already there for the > AT_SYMLINK_NOFOLLOW. Special credit goes to Past Seebs, who thoughtfully made the parser for

Re: [OE-core] [PATCH pseudo] ports/linux: wrap faccessat()

2019-08-01 Thread Seebs
On Thu, 1 Aug 2019 18:02:06 +0200 Max Kellermann wrote: > + * wrap_access(int dirfd, const char *path, int mode, int flags) { This should probably say "faccessat". I know it's just a comment, but I try to be consistent about these. > + rc = real___fxstatat64(_STAT_VER, dirfd, path, , >

Re: [OE-core] [PATCH] pseudo: Update to gain key bugfixes

2019-04-13 Thread Seebs
On Sat, 13 Apr 2019 10:03:03 +0200 Andreas Müller wrote: > On Fri, Apr 12, 2019 at 10:18 AM > wrote: > > > > On Wed, 2019-04-10 at 18:59 -0500, Seebs wrote: > > > On Thu, 11 Apr 2019 00:12:54 +0100 > > > Richard Purdie wrote: > > > > > >

Re: [OE-core] [PATCH] pseudo: Update to gain key bugfixes

2019-04-10 Thread Seebs
On Thu, 11 Apr 2019 00:12:54 +0100 Richard Purdie wrote: > -SRCREV = "6294b344e5140f5467e6860f45a174440015304e" > +SRCREV = "6ebc7d6bc8ab973d0ba949eeb363821811ce8dc5" I would sort of recommend one of the two commits since then -- one may fix the .NET startup failures, and the other fixes

Re: [OE-core] [PATCH] Handle OFD lock flags

2019-01-15 Thread Seebs
On Tue, 15 Jan 2019 13:31:13 +0100 Stefan Agner wrote: > + case F_OFD_GETLK: > + case F_OFD_SETLK: > + case F_OFD_SETLKW: These probably need an #ifdef for systems that don't have those names yet, but otherwise this looks reasonable? -s --

Re: [OE-core] [PATCH] pseudo: fix link of sqlite3 using pkg-config

2018-11-18 Thread Seebs
On Sun, 18 Nov 2018 19:36:46 +0100 Jens Rehsack wrote: > + for sqlite_link_opt in $(pkg-config sqlite3 --libs --static) Ugh, but yeah, I think this is probably needed. I'm a bit concerned about libsqlite3 ending up with readline included, that really seems like something that should only be

Re: [OE-core] [pseudo] [RFC 1/2] pseudo_ipc.c: Use MSG_NOSIGNAL if available

2018-08-15 Thread Seebs
On Wed, 15 Aug 2018 10:27:29 +0100 Richard Purdie wrote: > On Wed, 2018-08-15 at 08:59 +0200, Rasmus Villemoes wrote: > > On 2018-07-11 16:30, Rasmus Villemoes wrote: > > > MSG_NOSIGNAL has been in Linux since 2.2, and has been > > > standardized in > > > POSIX 2008. Using that when available

Re: [OE-core] [PATCH] pseudo: use latest SRCREV

2018-04-20 Thread Seebs
On Fri, 20 Apr 2018 08:25:26 + Martin Jansa wrote: > * the pseudo.log is significantly shorter with this revision There's also an actually fairly significant bug fix in here. At one point, long ago, I made a function that expands paths, and takes a flag argument

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

2018-04-04 Thread Seebs
On Wed, 4 Apr 2018 14:28:11 -0700 Khem Raj wrote: > what is the performance impact of adding another stack frame and > function call in the chain here. Do we have data ? Very close to unmeasurable, because *almost nothing ever uses syscall*. This is used only for the case

Re: [OE-core] [PATCH] pseudo: Upgrade to latest master

2018-04-03 Thread Seebs
On Tue, 3 Apr 2018 10:51:28 +0100 Richard Purdie wrote: > This change includes several bug fixes and improvements, including > better path handling (the existance of . and .. for files), handling > of the sticky bit, and syscall renameat2 handling and

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

2018-03-31 Thread Seebs
On Sat, 31 Mar 2018 16:03:01 -0500 Joshua Watt wrote: > Looks like maybe gdk-pixbuf-query-loaders has the unlucky honour of > being one of the few programs that invokes the pseudo syscall() > wrapper before any other functions that pseudo wraps and the missing > initializer

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

2018-03-31 Thread Seebs
On Sat, 31 Mar 2018 14:12:55 +0100 Richard Purdie wrote: > I believe that libglib-2.0 does use syscall() for something and that > the above programs are calling into it and faulting. Interesting! I'll poke around and see what I can find. -s --

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

2018-03-31 Thread Seebs
On Fri, 30 Mar 2018 23:02:29 -0700 Andre McCurdy <armccu...@gmail.com> wrote: > On Fri, Mar 30, 2018 at 10:06 PM, Seebs <se...@seebs.net> wrote: > > That's the problem: There's no sane way to express "the size that > > you would have gotten for these arguments of

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

2018-03-30 Thread Seebs
On Fri, 30 Mar 2018 21:15:18 -0700 Andre McCurdy wrote: > Arguments passed by the caller will be put on the stack before any > stack frame is created by the callee. You can argue about which way a > stack grows (up or down) but however you define it, reading past the > end of

Re: [OE-core] pseudo: host user contamination

2018-03-29 Thread Seebs
On Thu, 29 Mar 2018 14:04:00 +0200 Enrico Scholz wrote: > __builtin_apply() should deal with it. The documentation hints at possible problems when dealing with other functions, but doesn't mention any architecture difficulties. It's possible gcc simply never uses

Re: [OE-core] pseudo: host user contamination

2018-03-27 Thread Seebs
On Tue, 27 Mar 2018 13:52:28 -0700 Andre McCurdy <armccu...@gmail.com> wrote: > On Tue, Mar 27, 2018 at 1:20 PM, Seebs <se...@seebs.net> wrote: > > My concern is that, strictly speaking, this is nearly all undefined > > behavior, and that reading more arguments tha

Re: [OE-core] pseudo: host user contamination

2018-03-27 Thread Seebs
On Tue, 27 Mar 2018 13:12:19 -0700 Andre McCurdy wrote: > If you mean forwarding arguments through a wrapper without > interpreting them then I don't know what your concern is. Forwarding > arguments can be handled completely generically - for any architecture > and any

Re: [OE-core] pseudo: host user contamination

2018-03-27 Thread Seebs
On Tue, 27 Mar 2018 21:20:24 +0200 Enrico Scholz wrote: > SYS_readahead is one of a few syscalls which pass 64 bit arguments on > 32 bit architectures. Without the manual splitting, the ABI will > cause the compiler to insert a dummy argument so that registers

Re: [OE-core] pseudo: host user contamination

2018-03-27 Thread Seebs
On Tue, 27 Mar 2018 12:11:22 -0700 Andre McCurdy wrote: > In the readahead example, the first syscall argument is the > 32bit file descriptor (which will be passed to the kernel in r0), > therefore a padding argument is required to fill r1 and ensure that > the first word of

Re: [OE-core] pseudo: host user contamination

2018-03-27 Thread Seebs
On Tue, 27 Mar 2018 18:26:05 +0200 Enrico Scholz wrote: > Perhaps we have different man pages but e.g. [1] mentions only > registers in the context of the kernel interface but not when > entering/leaving syscall(2) itself. And yet, it's syscall(2) doing the

Re: [OE-core] pseudo: host user contamination

2018-03-27 Thread Seebs
On Tue, 27 Mar 2018 18:35:32 +0200 Enrico Scholz wrote: > Does this really matter here? Because the caller has to set them > accordingly the ABI, you can extract the arguments by > > int olddirfd= va_arg(ap, int); > char const *oldpath =

Re: [OE-core] pseudo: host user contamination

2018-03-27 Thread Seebs
On Tue, 27 Mar 2018 16:42:03 +0200 Enrico Scholz wrote: > will work to wrap syscall(2). Params for _renameat2_syscall() can be > extracted by va_args. Does anyone have access to an actual 64-bit EABI ARM system to verify the argument passing for renameat2

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

2018-03-27 Thread Seebs
On Tue, 27 Mar 2018 16:48:02 +0100 Ross Burton wrote: > This patch intercepts syscall() and returns ENOTSUP if renameat2() is > being called. I am inclined to NAK this until we have a clearer understanding of the mechanics observed in glibc's syscall implementation; it's

Re: [OE-core] pseudo: host user contamination

2018-03-27 Thread Seebs
On Tue, 27 Mar 2018 15:06:40 +0200 Enrico Scholz wrote: > Andre McCurdy > writes: > > >> Since the man page gave the ia64 example, I went and checked, and > >> it is indeed the case that calls other than

Re: [OE-core] pseudo: host user contamination

2018-03-26 Thread Seebs
On Mon, 26 Mar 2018 19:59:09 -0700 Andre McCurdy wrote: > The syscall manpage is from the kernel manpages, not glibc. > http://man7.org/linux/man-pages/man2/syscall.2.html And yet! glibc is setting those registers in its code. Why? If that's a kernel thing and libc

Re: [OE-core] pseudo: host user contamination

2018-03-26 Thread Seebs
On Mon, 26 Mar 2018 18:34:10 -0700 Andre McCurdy wrote: > > I remain interested in why the glibc implementation does all these > > weird things on some architectures if none of those things matter. > > Which glibc implementation? I'll take a look. syscall(2) for various

Re: [OE-core] pseudo: host user contamination

2018-03-26 Thread Seebs
On Mon, 26 Mar 2018 18:10:07 -0700 Andre McCurdy wrote: > I've verified that the QA warnings on FC27 can be fixed by preloading > a wrapper for libc syscall(). Just a proof of concept but if anyone > would like to reproduce it my steps are below. Yes, I think we were

Re: [OE-core] pseudo: host user contamination

2018-03-26 Thread Seebs
On Mon, 26 Mar 2018 13:12:44 -0700 Andre McCurdy wrote: > That's based on your assumption that a C wrapper needs to care about > results in architecture specific registers, which I contend is not a > correct interpretation of the syscall manpage. My observation is: If this

Re: [OE-core] pseudo: host user contamination

2018-03-26 Thread Seebs
On Mon, 26 Mar 2018 20:49:30 +0200 Andreas Müller wrote: > Interesting background: mv/renameat2 change seemed so important for > Fedora that they backported the changes into 8.27. It looks like the reason for this is the RENAME_NOREPLACE flag, which avoids a possible

Re: [OE-core] pseudo: host user contamination

2018-03-24 Thread Seebs
On Sat, 24 Mar 2018 15:22:47 -0500 Joshua Watt wrote: > I don't think that is true. libc's syscall() must conform to the *C* > ABI for the system... if the kernel does things that aren't in line > with the C ABI (like return things in registers that aren't expected, > fail

Re: [OE-core] pseudo: host user contamination

2018-03-24 Thread Seebs
On Sat, 24 Mar 2018 12:42:45 -0700 Andre McCurdy wrote: > Right. The musl example is to show how it's possible to transparently > intercept and pass on any call to the syscall() ABI without > interpreting anything. Yes, if you don't need to interpret things, and aren't

Re: [OE-core] pseudo: host user contamination

2018-03-24 Thread Seebs
On Sat, 24 Mar 2018 11:59:27 -0700 Andre McCurdy wrote: > The EABI example applies to 64bit values on 32bit architectures. Since > pointers are 32bit values on 32bit architectures the example doesn't > apply to renameat2 (which only passes int's and pointers - nothing >

Re: [OE-core] pseudo: host user contamination

2018-03-24 Thread Seebs
On Sat, 24 Mar 2018 11:12:20 -0700 Andre McCurdy wrote: > If you can successfully intercept the libc syscall() API and return > ENOTSUPP for the one specific case of renameat2 but pass on all other > callers transparently then haven't you've already solved the bulk of > the

Re: [OE-core] pseudo: host user contamination

2018-03-24 Thread Seebs
On Sat, 24 Mar 2018 17:10:47 + "Burton, Ross" wrote: > On 24 March 2018 at 12:36, Richard Purdie > wrote: > > I think, at least in principle, pseudo could wrap that and intercept > > this particular syscall, check syscall_number

Re: [OE-core] pseudo: host user contamination

2018-03-24 Thread Seebs
On Sat, 24 Mar 2018 12:36:28 + Richard Purdie wrote: > I think, at least in principle, pseudo could wrap that and intercept > this particular syscall, check syscall_number (the numbering having > its own set of issues) and then only handle the specific

Re: [OE-core] pseudo: host user contamination

2018-03-23 Thread Seebs
On Fri, 23 Mar 2018 18:43:12 -0700 Andre McCurdy wrote: > Since glibc doesn't provide a wrapper for renameat2, making the > syscall via the libc syscall() API is exactly what coreutils (actually > gnulib) should be doing. There would certainly be grounds to complain > if

Re: [OE-core] pseudo: host user contamination

2018-03-23 Thread Seebs
On Fri, 23 Mar 2018 18:10:21 -0700 Andre McCurdy wrote: > The syscall wrapper in musl handles 6 additional arguments - > unconditionally. Based on that you might not need to interpret > anything - just extract 6 arguments and pass them on? > > long syscall(long n, ...) > {

Re: [OE-core] pseudo: host user contamination

2018-03-23 Thread Seebs
On Fri, 23 Mar 2018 17:33:28 -0700 Andre McCurdy wrote: > Interposing the libc syscall wrapper doesn't seem to scary if you can > transparently pass on everything apart from syscall(SYS_renameat2, > ...) ? I don't think I can in the general case; I don't know how many

Re: [OE-core] pseudo: host user contamination

2018-03-23 Thread Seebs
On Fri, 23 Mar 2018 23:47:30 + Richard Purdie <richard.pur...@linuxfoundation.org> wrote: > On Fri, 2018-03-23 at 11:49 -0500, Seebs wrote: > > On Fri, 23 Mar 2018 16:30:55 + > > "Burton, Ross" <ross.bur...@intel.com> wrote: > > > > >

Re: [OE-core] pseudo: host user contamination

2018-03-23 Thread Seebs
On Fri, 23 Mar 2018 16:56:16 + "Burton, Ross" <ross.bur...@intel.com> wrote: > On 23 March 2018 at 16:49, Seebs <se...@seebs.net> wrote: > > On Fri, 23 Mar 2018 16:30:55 + > > "Burton, Ross" <ross.bur...@intel.com> wrote: > > &g

Re: [OE-core] pseudo: host user contamination

2018-03-23 Thread Seebs
On Fri, 23 Mar 2018 16:30:55 + "Burton, Ross" wrote: > Because in GNU's infinite wisdom they're using renameat2() to do > atomic renames in the mv command, and as renameat2 isn't in the > headers for F27 it just does a syscall directly. This is in upstream > coreutils

Re: [OE-core] pseudo: host user contamination

2018-03-23 Thread Seebs
On Fri, 23 Mar 2018 17:10:35 +0100 Enrico Scholz wrote: > I think, 'mv' is the culprit. It calls 'renameat2()' directly over > 'syscall()': > > | $ ltrace mv foo bar > | ... > | syscall(316, 0xff9c, 0x7fff1564a341, > 0xff9c)

Re: [OE-core] [PATCH] pseudo: explicitly enable xattr support

2018-03-22 Thread Seebs
On Thu, 22 Mar 2018 17:06:08 +0100 Andreas Kaufmann wrote: > Pseudo is using a custom configure script that detects if it shall > build with extended file attribute support or not. The check is done > by simply calling 'getfattr' provided by attr-native which is

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-03-01 Thread Seebs
On Thu, 1 Mar 2018 15:53:46 +0200 Alexander Kanavin wrote: > toomanyfiles.patch rebased Do we still have a reason for that, if we're using epoll to address that? That said, with the new fastop sanity-fix, that is probably much less dangerous than it used to

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-19 Thread Seebs
On Mon, 19 Feb 2018 20:01:31 +0100 Martin Jansa wrote: > I did quick check for UID/GID issue: > https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434 Hmm. glibc-locale, in particular, is a really weird case; does it still do the strange thing with copying the files

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-19 Thread Seebs
On Mon, 19 Feb 2018 11:27:56 +0200 Alexander Kanavin wrote: > > Huh. It's possible that the initial "don't try to close fd 0" was > > correct, and the real problem is that the attempt is getting made > > mistakenly. I'll study that more; the epoll code was a

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-17 Thread Seebs
On Sat, 17 Feb 2018 15:28:55 +0200 Alexander Kanavin wrote: > For me, with epoll enabled: > > b6a015a works > 23f089f and 26e30fa both lock up Huh. It's possible that the initial "don't try to close fd 0" was correct, and the real problem is that the attempt

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-16 Thread Seebs
On Fri, 16 Feb 2018 20:11:48 +0100 Martin Jansa wrote: > I didn't get to the logs yet, but with this change added I see many > do_install tasks failing with exit code '134'. Huh, that's SIGABRT. I'll see if I can reproduce. -s --

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-16 Thread Seebs
ith this change included got stuck until disk space run out.. Oh-hoh! That could be the epoll thing that I wasn't able to reproduce. > commit 26e30fa2e1a0fe4e885d7eea3f55d23cd2c3158f > Author: Seebs <se...@seebs.net> > Date: Fri Feb 16 11:49:49 2018 -0600 > > Allow c

Re: [OE-core] [PATCH][PSEUDO 0/4] Fix stripped mode with newer coreutils cp

2017-11-29 Thread Seebs
On Wed, 29 Nov 2017 12:02:38 -0600 Richard Tollerton wrote: > So we noticed that cp -Rp was stripping special bits off of > directories when run under pseudo. The super interesting thing was > that people saw this when upgrading their build machines from Ubuntu > 12.04 to

Re: [OE-core] [PATCH 2/2] pseudo: Add fastop reply fix

2017-09-22 Thread Seebs
On Fri, 22 Sep 2017 17:41:17 +0100 Richard Purdie wrote: > This changes the pseudo FASTOP functionality so that a reply to the > operation is required. This means we then cannot lose data if a > connection is closed. This in turn stops corruption if we run out

Re: [OE-core] [PATCHv2] pseudo: use epoll API on Linux

2017-09-18 Thread Seebs
On Mon, 18 Sep 2017 19:41:03 -0400 Trevor Woerner wrote: > Would you be open to a co-maintainership? Maybe a co-maintainer who > doesn't push to master directly? Maybe? I don't know, I'd need to think about that a bit. I recognize that there's a need to get some of this

Re: [OE-core] [PATCHv2] pseudo: use epoll API on Linux

2017-09-18 Thread Seebs
On Mon, 18 Sep 2017 19:16:13 -0400 Trevor Woerner wrote: > It doesn't make sense to carry these large patches against pseudo in > OE itself. Isn't pseudo one of the tools under The Yocto Project > umbrella? Yes. But the pool of people with the variety of expertise needed to

Re: [OE-core] [pseudo][PATCH] Fix to fcntl guts to ignore flags that can be ORed into cmd

2017-09-16 Thread Seebs
On Sat, 16 Sep 2017 02:22:01 + Will Page wrote: > Thanks, Ross. > > I had contacted the maintainer off list to ask where I should submit > my patch. I may have misunderstood his reply. No, I'm just confused, because I'm not really otherwise active in yocto/oe-core these

Re: [OE-core] [pseudo][PATCH] Fix to fcntl guts to ignore flags that can be ORed into cmd

2017-09-15 Thread Seebs
On Fri, 15 Sep 2017 15:27:00 -0700 Will Page wrote: > The fcntl guts switch on "cmd" parameter to identify the fcntl > command being issued, but isn't aware of the file creation flags that > can be ORed in. This is true. I was, in fact, not aware of those flags. Looks

Re: [OE-core] [PATCH] useradd: don't override pseudo environment

2017-09-15 Thread Seebs
On Fri, 15 Sep 2017 12:58:48 +0100 Ross Burton wrote: > Remove the PSEUDO_LOCALSTATEDIR assignment and inherit the correct > assignment in FAKEROOTENV. Nice catch! This probably explains a LOT of the strange behaviors we've been seeing. -s --

Re: [OE-core] [RFC][PATCH] insane.bbclass: Add do_qa_pseudo function to check for common errors listed in pseudo.log

2017-09-14 Thread Seebs
On Thu, 14 Sep 2017 15:53:09 +0100 "Burton, Ross" wrote: > Example: > > path mismatch [5 links]: ino 27539515 db > '/data/poky-tmp/master/build/work/corei7-64-poky-linux/dbus/1.10.20-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/x86_64-poky-linux-ld.bfd' > req >

Re: [OE-core] [RFC][PATCH] insane.bbclass: Add do_qa_pseudo function to check for common errors listed in pseudo.log

2017-09-14 Thread Seebs
On Thu, 14 Sep 2017 00:28:34 +0200 Martin Jansa wrote: > OK, thanks. > > Any insights to the first issue described in commit message? That we > know that is an Actual Problem, but hard to reproduce it. This one? glibc-locale-2.26: glibc-locale:

Re: [OE-core] [RFC][PATCH] insane.bbclass: Add do_qa_pseudo function to check for common errors listed in pseudo.log

2017-09-13 Thread Seebs
On Wed, 13 Sep 2017 22:50:32 +0200 Martin Jansa wrote: > inode mismatch: > '/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/systemd/1_234-r0/recipe-sysroot/etc/group' > ino 29361846 in db, 29361904 in request. Just to be clear about this: This is at least potentially

Re: [OE-core] [RFC][PATCH] insane.bbclass: Add do_qa_pseudo function to check for common errors listed in pseudo.log

2017-09-13 Thread Seebs
On Wed, 13 Sep 2017 22:46:59 +0200 Martin Jansa wrote: > And some-other-unrelated-file is really some different file, not > just hardlink to the same file from some different directory (like > between WORKDIR and sysroot other "path mismatch" entries show). To clarify

Re: [OE-core] [PATCH 1/2] scripts: change way we find native tools (pseudo)

2017-04-04 Thread Seebs
On Tue, 4 Apr 2017 15:22:10 -0700 brian avery wrote: > oe-find-native-sysroot: Recipe Specific Sysroots have eliminated the > large STAGING_DIR_NATIVE. Now, we will rely on the meta-ide-support > sysroot that is what was populating the large STAGING_DIR_NATIVE in >

  1   2   >