<div class="gmail_quote"><div>Hi. My link was wrong.</div><div>You can access below probably, like a link "Tizen" at toybox main page.</div><div><a href="https://git.tizen.org/cgit/external/tizen-coreutils.git/tree/packaging/coreutils-6.9-smack.patch?h=tizen_2.3" target="_blank">https://git.tizen.org/cgit/external/tizen-coreutils.git/tree/packaging/coreutils-6.9-smack.patch?h=tizen_2.3</a></div><div> </div><div>And share one more site : <a href="http://schaufler-ca.com/description_from_the_linux_source_tree" target="_blank">http://schaufler-ca.com/description_from_the_linux_source_tree</a></div><div>This is smack project community, and Schaufler is the founder of this project.</div><div>It includes "Applying Access Rules" section more. Is it helpful for you? </div><div> </div><div>Actually, Above tizen-coreutils patch also wasn't made by tizen team with considering TRANSMUTE flag I think. </div><div> </div><div><br> </div><div class="gmail_quote"><div><div class="h5">2015-07-02 4:41 GMT+09:00 Rob Landley <span dir="ltr"><<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><span>On 07/01/2015 12:17 AM, Hyejin Kim wrote:<br>
> There is a reference in tizen, repository called external/tizen-coreutils<br>
> It has a patch to cover smack feature into some commands.<br>
><br>
> <a href="https://review.tizen.org/gerrit/gitweb?p=external/tizen-coreutils.git;a=blob;f=packaging/coreutils-6.9-smack.patch;h=1ac188e50938d51c4ac8f2ce605580ee1b8da2f0;hb=HEAD" target="_blank" rel="noreferrer">https://review.tizen.org/gerrit/gitweb?p=external/tizen-coreutils.git;a=blob;f=packaging/coreutils-6.9-smack.patch;h=1ac188e50938d51c4ac8f2ce605580ee1b8da2f0;hb=HEAD</a><br>
> (If you can't access this, plz register account or let me know)<br>
<br>
</span>It popped up a login request and wouldn't let me access the page without<br>
a username/password, and there was no obvious link to account creation<br>
from the error page.<br>
<br>
If I need an account to view the source, it's not an open source project.<br>
<span><br>
> I guess it will be helpful that you understand their intention more.<br>
><br>
> As Jose mentioned, there is one more xattr for directory, named<br>
> security.SMACK64TRANSMUTE (Now what we are using to save label is<br>
> security.SMACK64)<br>
> plz, refer to the explanation.<br>
<br>
</span>Below, or at the link above?<br>
<span><br>
> What is __security.SMACK64TRANSMUTE__ ?<br>
> ==> Can only have the value "TRUE".<br>
<br>
</span>So they've reinvented the sticky bit with a new meaning. And for some<br>
reason, it has a "64" in it. (Was there a SMACK32?)<br>
<span><br>
> If this attribute is present on a directory when an object is created in<br>
> the directory and the Smack rule (more below) that permitted the write<br>
> access to the directory includes the transmute ("t") mode<br>
> the object gets the label of the directory instead of the label of the<br>
> creating process. If the object being created is a directory the<br>
> SMACK64TRANSMUTE attribute is set as well.<br>
<br>
</span>The first patch I was sent (Krzysztof Sasiak <<a href="mailto:k.sasiak@samsung.com" target="_blank">k.sasiak@samsung.com</a>> in<br>
the tizen pull request) didn't do that. It only copied xattrs on files,<br>
not on directories or dev nodes or fifos or symlinks... (Can symlinks<br>
have xattrs?)<br></blockquote></div></div><div>symlink(or directory) can have its own label. it is tested by using chsmack command (in the smack-util)</div><div>Further this is a part of setxattr's man page. context is based on inode.</div><div> </div><div><h2><a href="http://man7.org/linux/man-pages/man2/setxattr.2.html#DESCRIPTION" target="_blank"></a>DESCRIPTION <a href="http://man7.org/linux/man-pages/man2/setxattr.2.html#top_of_page" target="_blank"><span>top</span></a></h2><pre> Extended attributes are <i>name</i>:<i>value</i> pairs associated with inodes
(files, directories, symbolic links, etc.). They are extensions to
the normal attributes which are associated with all inodes in the
system (i.e., the <a href="http://man7.org/linux/man-pages/man2/stat.2.html" target="_blank">stat(2)</a> data).</pre><pre><strong> setxattr</strong>() sets the <i>value</i> of the extended attribute identified by
<i>name</i> and associated with the given <i>path</i> in the filesystem. The <i>size</i>
argument specifies the size (in bytes) of <i>value</i>; a zero-length value
is permitted.
<b>lsetxattr</b>() is identical to <b>setxattr</b>(), except in the case of a
symbolic link, where the extended attribute is set on the link
itself, not the file that it refers to.
</pre></div><div><div class="h5"><div> </div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<br>
Presumably this avoids the issue of confusing your own cp -r by creating<br>
directories that then alter their contents to not match the original.<br>
(At least using the "set creation context" mode of labeling objects to<br>
avoid leaving an exploitable race window between create and label.)<br>
<br>
It's also the wrong thing to do. (If I'm going to do this at all, I want<br>
to do it right.) We already _know_ there are labels that do something on<br>
a directory, we're discussing one right now, is --preserve=context _not_<br>
supposed to preserve them? (How about --preserve=xattr?)<br>
<br>
The other question is how far up the tree does this check go? Can you cp<br>
-r into a directory that already has SMACK64TRANSMUTE on it? (Even if it<br>
only goes one level deep, it can still screw up the top level...)<br>
<span><br>
> For this reason, I guess that a file can't have a bucket of labels. and<br>
> security.SMACK64 xattr is just one per a file or path.<br>
<br>
</span>The second patch (from Jose, at<br>
<a href="http://lists.landley.net/pipermail/toybox-landley.net/2015-May/004184.html" target="_blank" rel="noreferrer">http://lists.landley.net/pipermail/toybox-landley.net/2015-May/004184.html</a><br>
) has this:<br>
<br>
+ flistxattr(fdin, list, listlen);<br>
+ for (name = list ; (name - list) < listlen ; name +=<br>
strlen(name)+1) {<br>
+ /* test if the xattribute have to be copied */<br>
+ if ((TT.preserve & p_xattr)<br>
+ || ((TT.preserve & p_mode) &&<br>
+ !<br>
strncmp(name,"system.posix_acl_",sizeof("system.posix_acl_")-1))<br>
+ || ((TT.preserve & p_context) &&<br>
+ !strncmp(name,"security.",sizeof("security.")-1)))<br>
+ {<br>
+ /* yes, try to copy it */<br>
+ if ((len = fgetxattr(fdin, name, 0, 0)) > 0 && (value =<br>
malloc(len))) {<br>
+ fgetxattr(fdin, name, value, len);<br>
+ err += !!fsetxattr(fdout, name, value, len, 0);<br>
+ free(value);<br>
+ } else err++;<br>
+ }<br>
+ }<br>
<br>
Note the two strncmp(), hardwiring in smack and selinux security label<br>
names without a config symbol. Those are operating on prefixes, which<br>
imply there could be multiple entries after them.<br>
<br>
I also very very vaguely remember enh or somebody mentioning that the<br>
selinux defaults can be something like a comma separated list of<br>
attributes, but really want to just pass through unmodified strings to<br>
let the existing infrastructure handle that if at all possible.<br>
<br>
The above snippet is from a cp_xattrs() function which is only called<br>
once, right after xsendfile(), and thus once again only operates on<br>
strings. (Which is inda broken in that it's handling both<br>
--preserve=xattrs and --preserve=context and the _first_ of those should<br>
definitely operate on everything.)<br>
<br>
If the definition is that --preserve=context only operates on files,<br>
then I can set the default creation context and reset it back to<br>
whatever it was right afterwards. (Unless the right thing to do is<br>
_clear_ it at the start because --preserve=context overrides creation<br>
context the same way -p overrides umask().)<br>
<br>
In theory I can have --preserve=xattr just copy xattrs for every node<br>
after creation in the loop, and --preserve=context set the creation<br>
context just on files after copying the contents, and that way if you<br>
specify both it may do it twice but at least for files it should both<br>
give you the right eventual result _and_ not have an obvious race where<br>
you can fiddle with a file's contents before the label shows up.<br>
<br>
(The really really annoying part is I feel like I'm putting more thought<br>
into this than the people who created it. I want somebody to tell _me_<br>
how to do this, without me being able to spot holes in the first 15<br>
seconds...)<br>
<span><br>
> Further, above link doesnt call flistxattr() like Jose did for cp command.<br>
<br>
</span>Above link didn't give me a page.<br>
<br>
Sigh, lemme see what I can dig up. Google for tizen-coreutils gives me<br>
<a href="https://review.tizen.org/git/?p=external/tizen-coreutils.git;a=tree" target="_blank" rel="noreferrer">https://review.tizen.org/git/?p=external/tizen-coreutils.git;a=tree</a><br>
and "log" on that says the most recent commit was almost 3 years ago,<br>
but let's see if I click on a commit and then cut and paste your link's<br>
hash into that URL...<br>
<br>
<a href="https://review.tizen.org/git/?p=external/tizen-coreutils.git;a=commit;h=1ac188e50938" target="_blank" rel="noreferrer">https://review.tizen.org/git/?p=external/tizen-coreutils.git;a=commit;h=1ac188e50938</a><br>
<br>
Unknown commit object.<br>
<br>
Nope. No idea how to navigate this. There are a couple of tags newer,<br>
but not tree commits? (Am I misunderstanding branches here? A log on the<br>
most recent tag gives me two commits, and when I click the newest _is_ a<br>
more recent commit than a log on the tree but it has no parent...?)<br>
<br>
If I was just wandering past and examining the repository I just found<br>
with Google (first hit for "tizen coreutils", I'd think development<br>
ceased years ago. It might have been included verbatim in a couple new<br>
releases by some sort of distro-wide tagging, but it hasn't even had<br>
bugfixes applied since 2012.<br>
<br>
I'm guessing this is not actually the case, merely the public face you<br>
present to the open source community?<br>
<br>
> Thanks.<br>
<span><font color="#888888"><br>
Rob<br>
</font></span></blockquote></div></div></div><br>
</div><br>