Olaf Buddenhagen, on Mon 19 Sep 2016 23:43:55 +0200, wrote:
> I don't know which threads you have read exactly; but there have been
> pretty conclusive discussions on this issue IMHO.
I'd be really good if such conclusions would have been written somewhere
else than a list thread :/
Samuel
Hi,
On Mon, Sep 05, 2016 at 09:55:44PM -1000, Brent W. Baccala wrote:
> On Thu, Sep 1, 2016 at 12:38 PM, Richard Braun wrote:
> > This was famously shown with the example of the
> > firmlink translator used in /tmp, which would cause the removal of
> > any file targeted by the firmlink on /tmp c
Hi,
On Tue, Sep 06, 2016 at 02:49:31PM -1000, Brent W. Baccala wrote:
> On Tue, Sep 6, 2016 at 2:05 AM, Richard Braun wrote:
[...]
> > The solution, whatever it is, should focus only on determining whether
> > a server can be trusted or not. This should affect everything (servers,
> > (active) t
On Tue, Sep 20, 2016 at 01:33:44AM +0200, Samuel Thibault wrote:
> I don't think we want to make /tmp use trustiness to determine whether
> to follow a translator or not. If as root I run
>
> settrans -c /tmp/foo /hurd/firmlink /some/where
>
> I'd expect only foo to be removed.
If we want to st
Hello,
I don't think we want to make /tmp use trustiness to determine whether
to follow a translator or not. If as root I run
settrans -c /tmp/foo /hurd/firmlink /some/where
I'd expect only foo to be removed.
Samuel
On Wed, Sep 07, 2016 at 03:57:08PM -1000, Brent W. Baccala wrote:
> OK, I understand. I personally lean in the direction of adding something
> like an "-xtrans" switch to find, telling it not to enter translators,
> because that's a lot clearer than usurping the interpretation of existing
> switch
On Wed, Sep 7, 2016 at 11:49 AM, Richard Braun wrote:
>
> We really, really don't want to make standard Unix tools aware of
> Hurd-specific stuff, because that allows us to completely reuse the
> work of others. With a trend towards systemd, it's even more likely
> that our efforts will be put in
On Tue, Sep 06, 2016 at 02:49:31PM -1000, Brent W. Baccala wrote:
> Consider the case with symlinks. If "rm" transversed them, it could be a
> big problem. Let's see... what's the option for that?... oh, there is
> none! Isn't that interesting? "rm" has no option to follow symlinks!
>
> "find"
"Brent W. Baccala" writes:
> I see that. It seems to still have that problem. I created a directory
> /root/baitdir, and put in it a file named 'bait'. As a non-privileged
> user, I created a firmlink in /tmp to /root/baitdir and rebooted. Voila!
> 'bait' vanished.
We recently discussed it a
On Tue, Sep 6, 2016 at 2:05 AM, Richard Braun wrote:
> On Mon, Sep 05, 2016 at 09:55:44PM -1000, Brent W. Baccala wrote:
> > I haven't been able to find any other places on my system where find uses
> > -xdev; just bootclean.sh, but my search has not been exhaustive.
> >
> > Obviously there's bee
On Mon, Sep 05, 2016 at 09:55:44PM -1000, Brent W. Baccala wrote:
> I haven't been able to find any other places on my system where find uses
> -xdev; just bootclean.sh, but my search has not been exhaustive.
>
> Obviously there's been a long history behind this problem, and I'm new on
> the scene
On Thu, Sep 1, 2016 at 12:38 PM, Richard Braun wrote:
> This was famously shown with the example of the
> firmlink translator used in /tmp, which would cause the removal of
> any file targeted by the firmlink on /tmp cleanup during system
> startup.
>
I see that. It seems to still have that pro
12 matches
Mail list logo