| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Or any call to comma_scan where 'opt' appears as the last item in 'optlist'.
|
|
The most likely reason for setfscreatecon to fail is that you don't have permission, and that's reported by the write return EACCES. There isn't really a "bad" context; they're just strings.
Before:
$ adb shell mkdir -Z x y
mkdir: bad -Z 'x'
After:
$ adb shell mkdir -Z x y
mkdir: -Z 'x' failed: Permission denied
Other than this, the ToT mkdir works fine with SELinux.
|
|
Broken by recent lib.h additions.
|
|
|
|
|
|
|
|
(Easier to genericize logic and reuse later in less or vi...)
|
|
|
|
command exits with high errno and assume it segfaulted.
|
|
|
|
|
|
|
|
|
|
|
|
racy gap between create/label.
|
|
|
|
|
|
|
|
|
|
defconfig output for ready command list, to reduce manual updating.
|
|
to greppable TODO annotations in the individual files. (grep -riw TODO)
|
|
|
|
Change-Id: I23174fb7b54d029784e6d7460368128113090079
|
|
Doing a world writeable mkdir and _then_ adding a label seems like a race
window, so set the global "create stuff with these labels" context, then
do the creates.
|
|
|
|
|
|
|
|
I have no idea why -Z isn't showing up in mkdir --help when enabled, I
need to look at that...
|
|
it's 1999 and every path ever is from cwd or root" api versions for sockets
and as a fallback of the open fails.
There are still some holes (symlink to socket with -L will give you info
about the symlink, not the socket, and symlink to a file you can't open will
give you info about the symlink, not the file) but the correct fix is
to make O_PATH work in the kernel for the LSM functions. (If we can read
this data by path, we should be able to read it by O_PATH. We should not
need two codepaths for this.)
|
|
make lib/lsm.h auto-include from toys.h.
|
|
strwidth() got called on ->extra which was NULL. Had some other bad effects
ala "ls -sk file1 file2 file3" ignored the -k. This should fix that too.
|
|
show label: at the start (yes, even "ls -R" in an empty dir).
|
|
portability.h to new lib/lsm.h. Update ls.c to use it.
Fix "ls . toys" (two directories when one is . or ..), which was filtering
out the . as something we shouldn't recurse into even though it was explicitly
listed on the command line. For some reason "ls -Z . toys" is still segfaulting
though (but "ls -Z ." isn't), need to figure out why...
|
|
Change-Id: I0ad65a40bf380d789c4396ebdc01be217901a2e3
|
|
|
|
terminal reset escape sequence) and add gettty() function to lib so terminal
gets reset even when we redirect stdout/stderr. (This is apparently the
expected behavior.)
|
|
And yes, I tested $PWD/私はガラスを食べられま す。それは私を傷つけません。
as a name and made it work. If you throw newlines or ascii escapes in the
name it'll use the fancy printing logic for chars, otherwise it does the
full utf8 fontmetrics deal.
|
|
|
|
and some cleanups while I was there.
|
|
|
|
|
|
symfollow true/false.)
|
|
under traversal. Pass through full flag set in dirtree_add_node(), add
dirtree_start() wrapper to provide symlink-only behavior (avoiding a lot
of DIRTREE_SYMFOLLOW*!!(logic) repeated in callers).
|
|
LLVM has its own nuts warnings about things that aren't wrong, but disabling
them with the relevant -Wno-* warning disabling command line option drives
gcc nuts because it's a command line option it doesn't recognize. (gcc 4.2.1
dies with an error. gcc 4.6 warns about it _only_ if it's warning about
something else. (PICK ONE, either you warn about this or you don't, distract
people from actual problems with noise about something clearly unrelated to
what just changed is extra-stupid.)
So just probe for it, and add the flag only if it doesn't complain about it
while we're producing an unrelated warning.
|
|
|
|
Previously we'd go into an infinite loop because we weren't
incrementing optargs.
Also add a missing flush so an error on stderr won't overtake the
escape code that resets reverse video.
Disclaimer: the new behavior isn't exactly like the desktop version;
surprisingly they try to open the next file _before_ they prompt. That
feels weird to me as a user, and seems like it would lead to a more
awkward implementation, but if you're more concerned about
authenticity...
|
|
|
