It is also possible to fix this on the FUSE side by changing the stat()
behaviour. But this doesn't have a high priority right now, because an
even cleaner behaviour will automatically come about with the
introduction of private namespaces. See the discussion in
http://thread.gmane.org/gmane.comp.f
So, are we instead to raise a bug on every program and script that
doesn't expect a brain-damaged response due to ~/.gvfs? And then expect
the maintainers of those programs to work around the brain damage? E.g.
`alsa force-reload' causes `lsof: WARNING: can't stat() fuse.gvfs-fuse-
daemon file sy
** Changed in: gvfs
Bugwatch: GNOME Bug Tracker #534284 => GNOME Bug Tracker #560658
Status: Invalid => Unknown
--
~/.gvfs causes various errors
https://bugs.launchpad.net/bugs/225361
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ub
** Changed in: gvfs (ALT Linux)
Status: Unknown => New
--
~/.gvfs causes various errors
https://bugs.launchpad.net/bugs/225361
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.c
If rsync errors out immediately because it gets an access denied error
opening one source file, then yes, I'd say you should file a bug report
against it. Well behaved tools, such as tar, print an error message and
carry on with the rest of the files they CAN operate on.
--
~/.gvfs causes variou
http://mail.gnome.org/archives/gvfs-list/2008-November/msg1.html
This link was meant to go in the previous message.
--
~/.gvfs causes various errors
https://bugs.launchpad.net/bugs/225361
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubun
Phillip Susi <[EMAIL PROTECTED]> writes:
> [ Should root be able to access everything? ]
BUGabundu is right, this discussion probably belongs somewhere else.
So let my just state my main point again: using --allow-root does not
have any negative side effects and would prevent many applications
fr
On Monday 17 November 2008 18:44:18 Nikolaus Rath wrote:
> I don't know about ecryptfs, but a fuse filesystem does not need to
> run as root in order for --allow-root to work (is this what you
> assume?).
We are going of topic and discussing something that should be done on a ML and
not on a BTS.
Nikolaus Rath wrote:
> There is a difference between being able to impose specific
> restrictions even on the root account (SELinux) and the root account
> in general not being able to access all files in /home (as happening
> with gvfs). In other words, using SELinux does not prevent you from
> ac
Phillip Susi <[EMAIL PROTECTED]> writes:
> Ralph Corderoy wrote:
>> It is a bug in that, under Unix, by design, that should *never* happen
>> to a process running as root.
>
> Maybe 20 years ago, but these days being root does NOT mean you can do
> anything ( take a look at SELinux ). Heck, even
Ralph Corderoy wrote:
> It is a bug in that, under Unix, by design, that should *never* happen
> to a process running as root.
Maybe 20 years ago, but these days being root does NOT mean you can do
anything ( take a look at SELinux ). Heck, even 20 years ago root ran
into issues like this with
fuse-utils version 2.7.2-1ubuntu2 has a debian/fuse.conf that's
identical to my /etc one, i.e. everything commented out, so perhaps
you're right about the survival from an older release.
--
~/.gvfs causes various errors
https://bugs.launchpad.net/bugs/225361
You received this bug notification be
Ralph Corderoy <[EMAIL PROTECTED]> writes:
> Nikolaus wrote:
>> > https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/225361/comments/11
>> > I understand this configuration of FUSE has been chosen because of
>> > security concerns, as opposed to using its allow_users or allow_root
>> > options.
>>
Nikolaus wrote:
> > https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/225361/comments/11
> > I understand this configuration of FUSE has been chosen because of
> > security concerns, as opposed to using its allow_users or allow_root
> > options.
>
> This is not a valid concern. In Ubuntu, allow
Ralph Corderoy <[EMAIL PROTECTED]> writes:
> Nikolaus Rath and S B, take a look at my earlier comment
> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/225361/comments/11 I
> understand this configuration of FUSE has been chosen because of
> security concerns, as opposed to using its allow_user
Phillip Susi wrote:
> That is really just a contributing factor, not the problem. The
> problem is that people are having utilities fail when they run into
> .gvfs because root can't access it ( and this is by design, not a bug
> ).
It is a bug in that, under Unix, by design, that should *never*
So, correct me if I'm wrong. There is no work around right now?
I run into this bug when I run the command:
$ sudo alsa reload
And I really need to use this command, because the audio on my system is
flat out not working. If there's any way to fix this, I'd really like to
know about it.
--
~/.g
I am not going to argue about the definition of a bug. But why was this
particular design chosen? It seems to me that it only causes the
problems described above and does not have any positive effects.
--
~/.gvfs causes various errors
https://bugs.launchpad.net/bugs/225361
You received this bug n
Ralph Corderoy wrote:
> Just to be clear, mounting .gvfs somewhere other than $HOME doesn't
> solve the problem this bug's covering IMO, which is that the filesystem
> breaks the Unix norm that root can stat anything.
That is really just a contributing factor, not the problem. The problem
is tha
** Bug watch added: GNOME Bug Tracker #560658
http://bugzilla.gnome.org/show_bug.cgi?id=560658
** Also affects: gvfs (ALT Linux) via
http://bugzilla.gnome.org/show_bug.cgi?id=560658
Importance: Unknown
Status: Unknown
--
~/.gvfs causes various errors
https://bugs.launchpad.net/bu
Just to be clear, mounting .gvfs somewhere other than $HOME doesn't
solve the problem this bug's covering IMO, which is that the filesystem
breaks the Unix norm that root can stat anything.
--
~/.gvfs causes various errors
https://bugs.launchpad.net/bugs/225361
You received this bug notification
How would I go about doing mounting my gvfs under /tmp? This bug is
causing me and at least several others to lose audio from our computers
altogether. I would like to know how to implement the workaround for
now. Would there be any side effects to mounting the gvfs in the /tmp
folder? Thanks.
> E
Philip - Yes, I think your best chance is to open a low importance bug
on the bugzilla, as the idea that is being proposed is separate from the
original bug report about the root user not having access to ~/.gvfs
--
~/.gvfs causes various errors
https://bugs.launchpad.net/bugs/225361
You received
I added my comments to the gnome bugzilla, but it is still marked as
invalid and I can't change it. Hopefully someone will change it back to
new until the idea is reviewed, or maybe I should file a new bug in
their bugzilla?
The location where .gvfs is mounted is likely an easily configurable
par
Your best chance of making that happen is probably to discuss your ideas
with the upstream developers.
--
~/.gvfs causes various errors
https://bugs.launchpad.net/bugs/225361
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bug
Hi all,
This is all good news, I just hope somebody takes ownership of the
bug and we, the poor users have some sort of solution by the end of
jaunty cycle.
--
Regards,
Shirish Agarwal
This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/
http://flossex
That is indeed possible, didn't see that one coming ;)
2008/11/4 Sameer D. Sahasrabuddhe <[EMAIL PROTECTED]>
>
> Even if each user has his/her own .gvfs, it can still be mounted as
> /tmp/gvfs-username! A lot of gnome utilities already do that, so it won't be
> a big deal. And of course, there sh
Even if each user has his/her own .gvfs, it can still be mounted as
/tmp/gvfs-username! A lot of gnome utilities already do that, so it won't be a
big deal. And of course, there should be no security issue in using /tmp, since
even root can't access gvfs mounts! ;)
--
~/.gvfs causes various e
If it is not necessary that each user has its own ./gvfs, than that indeed
is a good workaround
2008/11/4 Shirish Agarwal <[EMAIL PROTECTED]>
> Philip,
> Thanx. I would be happy with that outcome :)
> --
> Regards,
> Shirish Agarwal
> This email is licensed under
> http://cre
Philip,
Thanx. I would be happy with that outcome :)
--
Regards,
Shirish Agarwal
This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17
--
~/.gvfs causes various e
While the problem of root accessing the .gvfs mount point is expected
and will not be changed, the fact is that having .gvfs mounted in the
user's home directory causes a number of errors for a number of people
using a number of tools. I do not think there is any reason it needs to
be mounted in t
31 matches
Mail list logo
