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