Re: [OE-core] About pseudo's chmod

On 1 Aug 2016, at 0:57, Robert Yang wrote: Sorry, the steps were wrong, they should be: 1) Out of pseudo: $ umask 0022 $ touch file1 2) Under pseudo: $ ln file1 file2 $ chmod 777 file2 $ ls -l file1 file2 We can see that both file1 and file2's mode is 0777. But if we remove

Re: [OE-core] About pseudo's chmod

On 1 Aug 2016, at 15:01, Richard Purdie wrote: No, we're actually expecting it to retain the mode it was given via the hardlink under pseudo. This is what a real world system would do and in this case we could track it via pseudo since pseudo is loaded when the hardlink is created. It would

Re: [OE-core] About pseudo's chmod

On 1 Aug 2016, at 3:57, Robert Yang wrote: How about we track the src when hardlink, for example: I don't think I like this. Fundamentally, the problem here is making a hard link to a file outside of pseudo, and then modifying the file. Consider, if you will, what happens if you replace

Re: [OE-core] About pseudo's chmod

On 2 Aug 2016, at 3:32, Robert Yang wrote: > It is worth trying, I will try to remove os.chown() and os.chmod() from > package.bbclass to see what will happen: > > if not cpath.islink(file): > os.link(file, fpath) > fstat = cpath.stat(file) >

Re: [OE-core] About pseudo's chmod

On 2 Aug 2016, at 14:39, Mark Hatle wrote: The alternative to the 'ln' is a 'cp' operation. This is how it used to work until optimizations were added a few releases ago. It was observed that this saves a large amount of space -- but it had the unintended consequence of suddenly files are

Re: [OE-core] About pseudo's chmod

On 2 Aug 2016, at 10:12, Mark Hatle wrote: So the problem is -- pseudo is modifying the 'original' file perms, which on a new instance of the pseudo database then gets inherited. So we get unpredictable results if this is the first time through -- or not the first time through. Yeah. And

Re: [OE-core] About pseudo's chmod

On 2 Aug 2016, at 1:07, Robert Yang wrote: Currently, the problem in oe-core is: 1) bitbake gzip 2) Edit rpm-native or package.bbclass to make do_package re-run. 3) bitbake gzip After the first build, build/version.c in gzip-dbg is 0444, but after the second

Re: [OE-core] About pseudo's chmod

On 2 Aug 2016, at 1:44, Robert Yang wrote: Because the stat() gets 0644 on ${B}/version.c in the second run, so it would run chmod 0644 rather than 0444 on gzip-dbg/version.c. Why is it calling chmod at all? The goal is apparently to give gzip-dbg/version.c the same mode that ${B}/version.c

Re: [OE-core] About pseudo's chmod

On 1 Aug 2016, at 18:36, Mark Hatle wrote: Would it makes sense to track the xattrs and linked files and such using some type of inode reference (virtual or otherwise)? Since in the case of a hard link, on a normal Linux style filesystem, there will be a single inode that has a reference

Re: [OE-core] About pseudo's chmod

On 1 Aug 2016, at 17:55, Richard Purdie wrote: The trouble is that for speed, we do create trees of hardlinked files and play games with those and sstate amongst other things. Yeah. One concern would be ownership: If the things we're hardlinking to weren't created/tracked by pseudo initially,

Re: [OE-core] About pseudo's chmod

On 1 Aug 2016, at 20:52, Robert Yang wrote: And when remove file2, but file1's permission is changed, it should be considered as a bug. I'm not sure of that. My interpretation would be that hard linking under pseudo to files which weren't created under the same pseudo database is user error;

Re: [OE-core] About pseudo's chmod

is 0777. But if we remove file1: $ rm -f file1 $ ls file2 Now file2's mode is 0644 since the info had been removed from database. I don't get that result. Before the remove, I see: sqlite> select * from files; 1|/home/seebs/pseudo/f1|2054|2757274|0|0|33279|0|0 2|/home/seebs/pseudo/f2|2054|2757

Re: [OE-core] host-user-contaminated QA check

On Thu, 02 Feb 2017 20:43:49 +0100 Patrick Ohly wrote: > One could argue that an implicit "created during build -> owned by > root" follows the same logic. But as the check as it is now did find > a real issue and also others in the past (the pseudo bugs that Chris >

Re: [OE-core] host-user-contaminated QA check

On Thu, 02 Feb 2017 18:17:29 +0100 Patrick Ohly <patrick.o...@intel.com> wrote: > On Thu, 2017-02-02 at 11:12 -0600, Seebs wrote: > > > But I find mapping to root:root more attractive because it makes > > > packaging simpler (less worries about accidentally cop

Re: [OE-core] host-user-contaminated QA check

On Thu, 02 Feb 2017 11:38:00 +0100 Patrick Ohly wrote: > Why do we make the real user ID on the build system visible at all > when running under pseudo? The uid and user name have no meaning > there, as the user won't exist on the target system. Instead we could > map the

Re: [OE-core] host-user-contaminated QA check

On Thu, 02 Feb 2017 17:39:07 +0100 Patrick Ohly <patrick.o...@intel.com> wrote: > On Thu, 2017-02-02 at 10:21 -0600, Seebs wrote: > > On Thu, 02 Feb 2017 11:38:00 +0100 > > Patrick Ohly <patrick.o...@intel.com> wrote: > > > > > Why do we make the real

Re: [OE-core] pseudo 1.8.1 doesn't work with docker & dumb-init

On 1 Sep 2016, at 20:33, wenzong fan wrote: No, I didn't think it's related to any specific docker version. I tested it on "Docker version 1.7.1, build 786b29d" & "Docker version 1.11.2, build b9f10c9". BTW, I also tested the docker build w/o dumb-init, and the build works ... Yeah, it's

Re: [OE-core] pseudo 1.8.1 doesn't work with docker & dumb-init

On 31 Aug 2016, at 4:21, wenzong fan wrote: Finally I narrowed it down to pseudo commit: Yes, that makes sense, we expect that there'd be potential issues, but I didn't have a reproducer for any. Thanks! I'll see whether it reproduces for me now. Any specific version of docker I might need?

Re: [OE-core] [PATCH 1/1] pseudo: quiet diagnostics during startup for pseudo -d

On 29 Sep 2016, at 0:59, Robert Yang wrote: ...t-diagnostics-during-startup-for-pseudo-d.patch | 54 ++ ...er.c-add-prefix-for-log-and-make-log-cons.patch | 83 ++ .../files/0002-Use-correct-file-descriptor.patch | 53 ++

Re: [OE-core] [PATCH] pseudo: backport a patch to fix renameat()

On 6 Oct 2016, at 10:45, Joshua Lock wrote: renameat calls under pseudo were losing extended attributes. Backport the fix for this from pseudo upstream. ACKing this. Underlying problem was that renameat() was just totally busted, in a way rename() used to be busted. -s --

Re: [OE-core] pseudo 1.8.1 doesn't work with docker & dumb-init

On 7 Sep 2016, at 1:32, wenzong fan wrote: Yes, I believe it's not a 100 reproducible issue. Maybe you could run it with other builds in parallel and try it 3 times or more. I can try, but that might need bigger hardware than I have to hand at the moment. -s --

Re: [OE-core] [PATCH 0/1] pseudo: add prefix for log and make log consistent

On 28 Sep 2016, at 21:31, Robert Yang wrote: Thanks for the reply, I tested your patch from git repo, it doesn't work, the message goes to the terminal: Child process exit status 4: lock_held This, it turns out, is a result of a much worse bug which somehow previously evaded detection, and

Re: [OE-core] [PATCH 0/1] pseudo: add prefix for log and make log consistent

On 28 Sep 2016, at 21:31, Robert Yang wrote: Hi Peter, Thanks for the reply, I tested your patch from git repo, it doesn't work, the message goes to the terminal: Child process exit status 4: lock_held Huh. I'll have to look more closely, then. $ kill -9 `ps aux | grep /usr/bin/pseud |

Re: [OE-core] [PATCH 0/1] pseudo: add prefix for log and make log consistent

On 28 Sep 2016, at 22:34, Robert Yang wrote: Thanks, it works for me now, I will send a V2 with your patch sooner. How about the prefix issues? Which ones should be prefixed do you think please ? Yocto 2.2 may not need the prefix, but we can treat it as an enhancement for YP 2.3. I

Re: [OE-core] [PATCH 0/1] pseudo: add prefix for log and make log consistent

On 28 Sep 2016, at 1:22, Robert Yang wrote: meta/recipes-devtools/pseudo/files/0001-pseudo_server.c-add-prefix-for-log-and-make-log-cons.patch I don't think this produces desireable behavior in the command-line use case; so far as I can tell, this would result in getting no messages at all

Re: [OE-core] [PATCH][krogoth] pseudo: backport 'Work around issues with glibc 2.24'

On 28 Oct 2016, at 1:09, Enrico Jorns wrote: + #else +- if (e != NULL) { ++ /*if (e != NULL) { + pseudo_diag("No real function for %s: %s\n", func->name, e); +- } ++ }*/ + #endif Looking at upstream, I do have a fix

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

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 >

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

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] [PATCH] useradd: don't override pseudo environment

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] [pseudo][PATCH] Fix to fcntl guts to ignore flags that can be ORed into cmd

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] [PATCHv2] pseudo: use epoll API on Linux

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] [RFC][PATCH] insane.bbclass: Add do_qa_pseudo function to check for common errors listed in pseudo.log

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

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

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 2/2] pseudo: Add fastop reply fix

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] [pseudo][PATCH] Fix to fcntl guts to ignore flags that can be ORed into cmd

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] [PATCHv2] pseudo: use epoll API on Linux

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] [PATCH][PSEUDO 0/4] Fix stripped mode with newer coreutils cp

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] pseudo: update to latest master

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

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

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: update to latest master

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

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] [pseudo] [RFC 1/2] pseudo_ipc.c: Use MSG_NOSIGNAL if available

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: update to latest master

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: Upgrade to latest master

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

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: use latest SRCREV

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] pseudo: host user contamination

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

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

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

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

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] pseudo: host user contamination

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] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

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

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

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

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] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

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] pseudo: host user contamination

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

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

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

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

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

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

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

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] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

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] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

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

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] pseudo: host user contamination

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

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

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

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

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] [PATCH] pseudo: explicitly enable xattr support

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] pseudo: host user contamination

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

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

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

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] pseudo: host user contamination

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] [PATCH] pseudo: fix link of sqlite3 using pkg-config

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] [PATCH] Handle OFD lock flags

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: Update to gain key bugfixes

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] pseudo: Update to gain key bugfixes

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 v2] pseudo: Upgrade to latest to fix openat() with a directory symlink [NAK]

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]

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]

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]

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] ports/linux: wrap faccessat()

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: Upgrade to latest to fix openat() with a directory symlink

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: Drop static linking to sqlite3

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

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

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

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 13/25] pseudo: adjust for attr 2.4.48

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 13/25] pseudo: adjust for attr 2.4.48

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

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] [pseudo][PATCH] pseudo_util.c: Open file with O_CLOEXEC to avoid fd leak

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] [pseudo][PATCH] pseudo_util.c: Open file with O_CLOEXEC to avoid fd leak

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

  1   2   >