[Bradford] Symlink Permissions

[Alice Kaerast]

It's also worth mentioning that some software doesn't cope with symlinks.
It's rare, but I've seen software fail to write files because it was
pointed to a symlink rather than a directory. Needless to say I'm working
on replacing said software at the moment.

I'd be surprised if that's what you're seeing though, I'm fairly sure I've
done this exact same thing on a dev environment previously.

Regards
Alice

FOR PUBLIC SAFETY REASONS, THIS EMAIL HAS BEEN INTERCEPTED BY YOUR
GOVERNMENT AND WILL BE RETAINED FOR FUTURE ANALYSIS
On 21 Apr 2015 10:51, "David Spencer" <baildon.research at googlemail.com>
wrote:

> > Yesterday I was setting up a new Ubuntu Server to host some VMs using
> > libvirt.
> > I moved /var/lib/libvirt to a 2nd drive (mounted as /mnt/data) to
> > /mnt/data/libvirt/
> > I then created a soft link, checked the permissions (octal 750) and the
> > ownership.
> > But when I tried to create a new VM I got a permissions error.
> > Deleting the soft link  and moving libvirt back again to the root
> partition
> > and I can creating a new VM works.
>
> The only things that matter [1] are
> (1) the symlink must be in the right place, and
> (2) the symlink must be pointing to the right target, and
> (3) the ownership and permissions of the target must be right
>
> If I understand you right,
>
> ls -l /var/lib/libvirt
> should give you
> lrwxrwxrwx 1 owner1 group1 18 <date> /var/lib/libvirt -> /mnt/data/libvirt/
>
> ls -ld /mnt/data/libvirt/
> should give you
> drwxr-xr-x 2 owner2 group2 4096 <date> /mnt/data/libvirt/
>
> realpath -e /var/lib/libvirt
> should give you
> /mnt/data/libvirt
>
> If you're getting an error, then one or more of the above conditions
> 1-3 are not fulfilled, or you've given libvirt the wrong path, or
> libvirt is deleting and recreating or otherwise messing with the
> attributes of one or more of the components of the path or the
> "realpath", or maybe the effective permissions on the containing
> directories (/mnt/data or /mnt) are gratuitously restrictive.
>
> And then again, lots of people get confused about the 'source' and
> 'target' of the ln -s command; there is a case to be made that those
> arguments are not the right way round. (Unix considers them to be
> analogous to the cp command, but Multics had them the other way round.
> I don't necessarily endorse either point of view.)
>
> ttfn
> -D.
>
> [1] man 7 symlink
> http://man7.org/linux/man-pages/man7/symlink.7.html
>
> "The only time that the ownership of a symbolic link
> matters is when the link is being removed or renamed in a directory
> that has the sticky bit set (see stat(2)). [...]
> On Linux, the permissions of a symbolic link are not used in any
> operations; the permissions are always 0777 (read, write, and execute
> for all user categories), and can't be changed."
>
> _______________________________________________
> Bradford mailing list
> Bradford at mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/bradford
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/bradford/attachments/20150421/d568051f/attachment.html>