On Thu, 2009-09-03 at 10:47 +0100, Martin Orr wrote: > On 02/09/09 13:52, Stephen Smalley wrote: > > On Wed, 2009-09-02 at 13:24 +0100, Martin Orr wrote: > >> The reason I named the function that way was because the function with > >> _realpath expects a real path as an argument, but if this is confusing or > >> goes against a convention used elsewhere then it could be changed. > > > > Except that symlink_realpath() internally calls realpath(). I think it > > makes more sense to use process_one_realpath() for the function that > > invokes realpath(), and process_one() for the function that merely acts > > on its argument. > > > >> I copied the symlink_realpath code from what used to be in match. I assumed > >> that it needed a buffer on the stack because it then concatenates the last > >> component of the path on to that buffer, and realpath might not allocate a > >> long enough buffer. > > > > That's fair. > > > >>>> Not sure it is worth warning about the broken symlink case, and that > >>>> will trigger warnings for your existing users in the > >>>> restorecon /dev/stdin case, right? > >> I agree, it is not worth warning about broken symlinks, except maybe if -v > >> is specified. > > > > If the behavior of restorecon on symlinks is to always relabel the > > symlink and then if the target exists, relabel it as well, then it isn't > > truly an error if the target doesn't exist. It would be a bit clearer > > if we used an explicit flag like -h, as existing utilities like chown > > and chcon do, when we want to act on symlinks rather than their targets, > > but that would break existing usage it seems. > > > > Modified patch below. Seem reasonable? > > Looks fine to me. Ok, applied as policycoreutils 2.0.72. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
