Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #241868 > unrolled thread

Trying to setup obexd but Operation not permitted

Started bydeloptes <emanoil.kotsev@deloptes.org>
First post2021-11-04 17:50 +0100
Last post2021-11-05 19:30 +0100
Articles 18 — 5 participants

Back to article view | Back to linux.debian.user

Contents

  Trying to setup obexd but Operation not permitted deloptes <emanoil.kotsev@deloptes.org> - 2021-11-04 17:50 +0100
    Re: Trying to setup obexd but Operation not permitted Greg Wooledge <greg@wooledge.org> - 2021-11-04 18:10 +0100
      Re: Trying to setup obexd but Operation not permitted deloptes <emanoil.kotsev@deloptes.org> - 2021-11-04 19:40 +0100
        Re: Trying to setup obexd but Operation not permitted Burhan Hanoglu <burhanoglu@gmail.com> - 2021-11-04 20:50 +0100
          Re: Trying to setup obexd but Operation not permitted deloptes <emanoil.kotsev@deloptes.org> - 2021-11-05 09:50 +0100
            Re: Trying to setup obexd but Operation not permitted Greg Wooledge <greg@wooledge.org> - 2021-11-05 12:30 +0100
              Re: Trying to setup obexd but Operation not permitted deloptes <emanoil.kotsev@deloptes.org> - 2021-11-05 14:50 +0100
                Re: Trying to setup obexd but Operation not permitted Greg Wooledge <greg@wooledge.org> - 2021-11-05 16:10 +0100
                  Re: Trying to setup obexd but Operation not permitted Greg Wooledge <greg@wooledge.org> - 2021-11-05 17:00 +0100
                    Re: Trying to setup obexd but Operation not permitted David Wright <deblis@lionunicorn.co.uk> - 2021-11-05 17:10 +0100
                      Re: Trying to setup obexd but Operation not permitted deloptes <emanoil.kotsev@deloptes.org> - 2021-11-05 18:30 +0100
                        Re: Trying to setup obexd but Operation not permitted Greg Wooledge <greg@wooledge.org> - 2021-11-05 18:40 +0100
                          Re: Trying to setup obexd but Operation not permitted deloptes <emanoil.kotsev@deloptes.org> - 2021-11-05 19:20 +0100
                    Re: Trying to setup obexd but Operation not permitted deloptes <emanoil.kotsev@deloptes.org> - 2021-11-05 18:10 +0100
                      Re: Trying to setup obexd but Operation not permitted Greg Wooledge <greg@wooledge.org> - 2021-11-05 18:20 +0100
                        Re: Trying to setup obexd but Operation not permitted deloptes <emanoil.kotsev@deloptes.org> - 2021-11-05 19:10 +0100
                          Re: Trying to setup obexd but Operation not permitted "Thomas Schmitt" <scdbackup@gmx.net> - 2021-11-05 19:10 +0100
                            Re: Trying to setup obexd but Operation not permitted deloptes <emanoil.kotsev@deloptes.org> - 2021-11-05 19:30 +0100

#241868 — Trying to setup obexd but Operation not permitted

Fromdeloptes <emanoil.kotsev@deloptes.org>
Date2021-11-04 17:50 +0100
SubjectTrying to setup obexd but Operation not permitted
Message-ID<DfO65-6Xo-9@gated-at.bofh.it>
This is how I am starting the daemon

/usr/lib/bluetooth/obexd -d -n -r /home/user/Downloads -a

and this is what I get when trying to transfer a file

obexd[4068]: obexd/src/obex.c:obex_session_start()
obexd[4068]: obexd/src/obex.c:cmd_connect()
obexd[4068]: CONNECT(0x0), <unknown>(0xff)
obexd[4068]: obexd/src/obex.c:cmd_connect() Selected driver: Object Push
server
obexd[4068]: CONNECT(0x0), <unknown>(0x0)
obexd[4068]: obexd/src/obex.c:cmd_put()
obexd[4068]: PUT(0x2), <unknown>(0xff)
obexd[4068]: obexd/src/obex.c:parse_name() NAME: 20020011.jpg
obexd[4068]: obexd/src/obex.c:parse_length() LENGTH: 1207160
obexd[4068]: open(/home/user/Downloads/20020011.jpg): Operation not
permitted (1)
obexd[4068]: PUT(0x2), Forbidden(0x43)
obexd[4068]: obexd/src/obex.c:cmd_disconnect() session 0x5638a90b7140
obexd[4068]: DISCONNECT(0x1), <unknown>(0xff)
obexd[4068]: DISCONNECT(0x1), Success(0x20)
obexd[4068]: disconnected: Transport got disconnected
obexd[4068]: obexd/src/obex.c:obex_session_destroy()

ls -altr ~/Downloads/
total 24
drwxr-xr-x 197 user user 20480 Nov  4 08:06 ..
-rw-------   1 user user     0 Nov  4 17:35 20020011.jpg
drwx------   2 user user  4096 Nov  4 17:35 .


When I use tmp
/usr/lib/bluetooth/obexd -d -n -r /tmp -a

obexd[4087]: obexd/src/obex.c:obex_session_start()
obexd[4087]: obexd/src/obex.c:cmd_connect()
obexd[4087]: CONNECT(0x0), <unknown>(0xff)
obexd[4087]: obexd/src/obex.c:cmd_connect() Selected driver: Object Push
server
obexd[4087]: CONNECT(0x0), <unknown>(0x0)
obexd[4087]: obexd/src/obex.c:cmd_put()
obexd[4087]: PUT(0x2), <unknown>(0xff)
obexd[4087]: obexd/src/obex.c:parse_name() NAME: 20020011.jpg
obexd[4087]: obexd/src/obex.c:parse_length() LENGTH: 1207160
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=4096
obexd[4087]: obexd/src/obex.c:driver_write() 4096 written
obexd[4087]: PUT(0x2), Continue(0x10)
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=32567
obexd[4087]: obexd/src/obex.c:driver_write() 32567 written
obexd[4087]: obexd/src/obex.c:recv_data() name=20020011.jpg type=(null)
file=0x8 size=30652
obexd[4087]: obexd/src/obex.c:driver_write() 30652 written
obexd[4087]: obexd/src/obex.c:transfer_complete()
obexd[4087]: obexd/src/obex.c:cmd_disconnect() session 0x55efa7dd9180
obexd[4087]: DISCONNECT(0x1), <unknown>(0xff)
obexd[4087]: DISCONNECT(0x1), Success(0x20)
obexd[4087]: disconnected: Transport got disconnected


ls -al /tmp/
-rw-------  1 user user 232065 Nov  4 17:38  20020011.jpg


So why is file created in Downloads with zero size?! but can not transfer
content and in /tmp it works?
shouldn't obexd run with user permissions?

-- 
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0

[toc] | [next] | [standalone]

#241869

FromGreg Wooledge <greg@wooledge.org>
Date2021-11-04 18:10 +0100
Message-ID<DfOpr-7js-7@gated-at.bofh.it>
In reply to#241868
On Thu, Nov 04, 2021 at 05:44:31PM +0100, deloptes wrote:
> obexd[4068]: open(/home/user/Downloads/20020011.jpg): Operation not
> permitted (1)

That's an interesting message for that operation.

The open(2) man page shows only two possible sources for EPERM on an open:

       EPERM  The  O_NOATIME  flag was specified, but the effective user ID of
              the caller did not match the owner of the file  and  the  caller
              was not privileged.

       EPERM  The operation was prevented by a file seal; see fcntl(2).

I don't know whether this is truly a comprehensive list of causes.  I'm
wondering about things like FUSE-mounted file systems.  What kind of
file system is /home/user/Downloads/ part of?

I also have no idea what an obexd is, but I was wondering about AppArmor
(even though I think AppArmor causes EACCES not EPERM).  So:

unicorn:~$ apt-cache search obexd
bluez-obexd - bluez obex daemon

Then I looked at
<https://packages.debian.org/bullseye/amd64/bluez-obexd/filelist> but
I don't see any AppArmor profiles in that package.  Oh well.

[toc] | [prev] | [next] | [standalone]

#241870

Fromdeloptes <emanoil.kotsev@deloptes.org>
Date2021-11-04 19:40 +0100
Message-ID<DfPOy-824-7@gated-at.bofh.it>
In reply to#241869
Greg Wooledge wrote:

> That's an interesting message for that operation.
> 
> The open(2) man page shows only two possible sources for EPERM on an open:
> 
> EPERM  The  O_NOATIME  flag was specified, but the effective user ID of
> the caller did not match the owner of the file  and  the  caller
> was not privileged.
> 
> EPERM  The operation was prevented by a file seal; see fcntl(2).
> 
> I don't know whether this is truly a comprehensive list of causes.  I'm
> wondering about things like FUSE-mounted file systems.  What kind of
> file system is /home/user/Downloads/ part of?

Thank you,
yes it is interesting indeed, because obexd is started as the user and
should operate on behalf of the user.

/home/user/Downloads/ is on NFS share, but Downloads is writable only for
the user (700)

these are the mount options

type nfs4
(rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.40.68,local_lock=none,addr=192.168.40.40,_netdev)

IMO there is something fishy in obexd, because as you see it is able to
create the file, but not write the content and I am not that enlightened in
this matter :/.


-- 
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0

[toc] | [prev] | [next] | [standalone]

#241871

FromBurhan Hanoglu <burhanoglu@gmail.com>
Date2021-11-04 20:50 +0100
Message-ID<DfQUi-cY-5@gated-at.bofh.it>
In reply to#241870
On Thu, Nov 4, 2021 at 9:35 PM deloptes <emanoil.kotsev@deloptes.org> wrote:
>
> Greg Wooledge wrote:
>
> > That's an interesting message for that operation.
> >
> > The open(2) man page shows only two possible sources for EPERM on an open:
> >
> > EPERM  The  O_NOATIME  flag was specified, but the effective user ID of
> > the caller did not match the owner of the file  and  the  caller
> > was not privileged.
> >
> > EPERM  The operation was prevented by a file seal; see fcntl(2).
> >
> > I don't know whether this is truly a comprehensive list of causes.  I'm
> > wondering about things like FUSE-mounted file systems.  What kind of
> > file system is /home/user/Downloads/ part of?
>
> Thank you,
> yes it is interesting indeed, because obexd is started as the user and
> should operate on behalf of the user.
>
> /home/user/Downloads/ is on NFS share, but Downloads is writable only for
> the user (700)
>
> these are the mount options
>
> type nfs4
> (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.40.68,local_lock=none,addr=192.168.40.40,_netdev)
>
> IMO there is something fishy in obexd, because as you see it is able to
> create the file, but not write the content and I am not that enlightened in
> this matter :/.
>
>
> --
> FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
>

Could be something about that NFS mount. To narrow down; point it to
/home/user/something that is not on NFS but on the local FS instead
and see what happens.

-Burhan.

[toc] | [prev] | [next] | [standalone]

#241874

Fromdeloptes <emanoil.kotsev@deloptes.org>
Date2021-11-05 09:50 +0100
Message-ID<Dg358-7FG-21@gated-at.bofh.it>
In reply to#241871
Burhan Hanoglu wrote:

> Could be something about that NFS mount. To narrow down; point it to
> /home/user/something that is not on NFS but on the local FS instead
> and see what happens.

Hi,
yes it looks like it is somehow related, because on a local FS even with
same directory permissions (700) files are transferred fine.
So ... what is your opinion, where is the bug?

BR

-- 
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0

[toc] | [prev] | [next] | [standalone]

#241878

FromGreg Wooledge <greg@wooledge.org>
Date2021-11-05 12:30 +0100
Message-ID<Dg5zX-Qa-1@gated-at.bofh.it>
In reply to#241874
On Fri, Nov 05, 2021 at 09:32:27AM +0100, deloptes wrote:
> Burhan Hanoglu wrote:
> 
> > Could be something about that NFS mount. To narrow down; point it to
> > /home/user/something that is not on NFS but on the local FS instead
> > and see what happens.
> 
> Hi,
> yes it looks like it is somehow related, because on a local FS even with
> same directory permissions (700) files are transferred fine.
> So ... what is your opinion, where is the bug?

Check whether the systemd unit file is restricting network access for
the service/process.

[toc] | [prev] | [next] | [standalone]

#241885

Fromdeloptes <emanoil.kotsev@deloptes.org>
Date2021-11-05 14:50 +0100
Message-ID<Dg7Ls-23D-13@gated-at.bofh.it>
In reply to#241878
Greg Wooledge wrote:

> Check whether the systemd unit file is restricting network access for
> the service/process.

??? How do I do this - a hint would be helpful.

thanks in advance

-- 
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0

[toc] | [prev] | [next] | [standalone]

#241887

FromGreg Wooledge <greg@wooledge.org>
Date2021-11-05 16:10 +0100
Message-ID<Dg90S-2Yb-9@gated-at.bofh.it>
In reply to#241885
On Fri, Nov 05, 2021 at 02:46:18PM +0100, deloptes wrote:
> Greg Wooledge wrote:
> 
> > Check whether the systemd unit file is restricting network access for
> > the service/process.
> 
> ??? How do I do this - a hint would be helpful.

Start by figuring out the name of the service.

Then try "systemctl cat servicename > somefile".  This should produce
output that represents the entire unit file, possibly concatenating
multiple real files together,

Once you have that, you can look it over and see if anything pops out
at you.  If not, then you can try digging through the documentation
for each line, to see what it does.

[toc] | [prev] | [next] | [standalone]

#241888

FromGreg Wooledge <greg@wooledge.org>
Date2021-11-05 17:00 +0100
Message-ID<Dg9Nf-3ed-1@gated-at.bofh.it>
In reply to#241887
On Fri, Nov 05, 2021 at 10:59:46AM -0400, Greg Wooledge wrote:
> On Fri, Nov 05, 2021 at 02:46:18PM +0100, deloptes wrote:
> > Greg Wooledge wrote:
> > 
> > > Check whether the systemd unit file is restricting network access for
> > > the service/process.
> > 
> > ??? How do I do this - a hint would be helpful.
> 
> Start by figuring out the name of the service.
> 
> Then try "systemctl cat servicename > somefile".  This should produce
> output that represents the entire unit file, possibly concatenating
> multiple real files together,
> 
> Once you have that, you can look it over and see if anything pops out
> at you.  If not, then you can try digging through the documentation
> for each line, to see what it does.

Gaaah.  I just went back and found your original message.  You said
you're starting this daemon *by hand*, not through a systemd unit.

So, never mind.  Continue whatever other investigations you have lined
up.

[toc] | [prev] | [next] | [standalone]

#241889

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2021-11-05 17:10 +0100
Message-ID<Dg9WV-3wS-1@gated-at.bofh.it>
In reply to#241888
On Fri 05 Nov 2021 at 11:55:19 (-0400), Greg Wooledge wrote:
> On Fri, Nov 05, 2021 at 10:59:46AM -0400, Greg Wooledge wrote:
> > On Fri, Nov 05, 2021 at 02:46:18PM +0100, deloptes wrote:
> > > Greg Wooledge wrote:
> > > 
> > > > Check whether the systemd unit file is restricting network access for
> > > > the service/process.
> > > 
> > > ??? How do I do this - a hint would be helpful.
> > 
> > Start by figuring out the name of the service.
> > 
> > Then try "systemctl cat servicename > somefile".  This should produce
> > output that represents the entire unit file, possibly concatenating
> > multiple real files together,
> > 
> > Once you have that, you can look it over and see if anything pops out
> > at you.  If not, then you can try digging through the documentation
> > for each line, to see what it does.
> 
> Gaaah.  I just went back and found your original message.  You said
> you're starting this daemon *by hand*, not through a systemd unit.
> 
> So, never mind.  Continue whatever other investigations you have lined
> up.

Because both tests are run by hand, that does make it easier to strace
what's going on in more detail than the debug output. For example, the
open's flags are listed.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#241896

Fromdeloptes <emanoil.kotsev@deloptes.org>
Date2021-11-05 18:30 +0100
Message-ID<Dgbcl-4bt-1@gated-at.bofh.it>
In reply to#241889
David Wright wrote:

> Because both tests are run by hand, that does make it easier to strace
> what's going on in more detail than the debug output. For example, the
> open's flags are listed.

I forgot to mention that home is actually a link to home-lisa which is the
mount point for the NFS share.

I now used strace
writev(2, [{iov_base="obexd[23074]: PUT(0x2), <unknown"..., iov_len=39},
{iov_base="\n", iov_len=1}], 2) = 40
sendto(3, "<31>Nov  5 18:04:33 obexd[23074]"..., 59, MSG_NOSIGNAL, NULL, 0)
= 59
openat(AT_FDCWD, "/home/user/Downloads/20211105_090338.jpg", O_WRONLY
O_CREAT|O_TRUNC, 0600) = 8
fstat(8, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
lstat("/home", {st_mode=S_IFLNK|0777, st_size=10, ...}) = 0
readlink("/home", "home-lisa/", 4095)   = 10
lstat("/home-lisa", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/home-lisa/user", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
lstat("/home-lisa/user/Downloads", {st_mode=S_IFDIR|0700,
st_size=4096, ...}) = 0
lstat("/home-lisa/user/Downloads/20211105_090338.jpg", {st_mode=S_IFREG
0600, st_size=0, ...}) = 0
close(8)                                = 0
getpid()                                = 23074
writev(2, [{iov_base="obexd[23074]: open(/home/user"..., iov_len=92},
{iov_base="\n", iov_len=1}], 2) = 93
sendto(3, "<27>Nov  5 18:04:33 obexd[23074]"..., 112, MSG_NOSIGNAL, NULL, 0)
= 112
getpid()                                = 23074
writev(2, [{iov_base="obexd[23074]: PUT(0x2), Forbidde"..., iov_len=39},
{iov_base="\n", iov_len=1}], 2) = 40

so you see it resolves the link, but then fails with Forbidden.

Now I conducted the same test after createing a symlink to the local
directory (thus exclude NFS as root for the problem)

The result is the same
sendto(3, "<31>Nov  5 18:22:28 obexd[23364]"..., 59, MSG_NOSIGNAL, NULL, 0)
= 59
openat(AT_FDCWD, "/data/local/Downloads.test/20211105_090338.jpg", O_WRONLY
O_CREAT|O_TRUNC, 0600) = 8
fstat(8, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
lstat("/data", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/data/local", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/data/local/Downloads.test", {st_mode=S_IFLNK|0777, st_size=10, ...})
= 0
readlink("/data/local/Downloads.test", "Downloads/", 4095) = 10
lstat("/data/local/Downloads", {st_mode=S_IFDIR|0700, st_size=4096, ...}) =

0
lstat("/data/local/Downloads/20211105_090338.jpg", {st_mode=S_IFREG|0600,
st_size=0, ...}) = 0
close(8)                                = 0
getpid()                                = 23364
writev(2, [{iov_base="obexd[23364]: open(/data/local/D"..., iov_len=95},
{iov_base="\n", iov_len=1}], 2) = 96
sendto(3, "<27>Nov  5 18:22:28 obexd[23364]"..., 115, MSG_NOSIGNAL, NULL, 0)
= 115
getpid()                                = 23364
writev(2, [{iov_base="obexd[23364]: PUT(0x2), Forbidde"..., iov_len=39},
{iov_base="\n", iov_len=1}], 2) = 40
sendto(3, "<31>Nov  5 18:22:28 obexd[23364]"..., 59, MSG_NOSIGNAL, NULL, 0)
= 59

Conclusion: the problem is related to the directory link in the path and to
me it looks like a problem in obexd

How do you see this?

-- 
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0

[toc] | [prev] | [next] | [standalone]

#241897

FromGreg Wooledge <greg@wooledge.org>
Date2021-11-05 18:40 +0100
Message-ID<Dgbm2-4et-13@gated-at.bofh.it>
In reply to#241896
On Fri, Nov 05, 2021 at 06:24:38PM +0100, deloptes wrote:
> I now used strace
> writev(2, [{iov_base="obexd[23074]: PUT(0x2), <unknown"..., iov_len=39},
> {iov_base="\n", iov_len=1}], 2) = 40
> sendto(3, "<31>Nov  5 18:04:33 obexd[23074]"..., 59, MSG_NOSIGNAL, NULL, 0)
> = 59
> openat(AT_FDCWD, "/home/user/Downloads/20211105_090338.jpg", O_WRONLY
> O_CREAT|O_TRUNC, 0600) = 8

So... the open actually *worked*.

> fstat(8, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
> lstat("/home", {st_mode=S_IFLNK|0777, st_size=10, ...}) = 0
> readlink("/home", "home-lisa/", 4095)   = 10
> lstat("/home-lisa", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat("/home-lisa/user", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> lstat("/home-lisa/user/Downloads", {st_mode=S_IFDIR|0700,
> st_size=4096, ...}) = 0
> lstat("/home-lisa/user/Downloads/20211105_090338.jpg", {st_mode=S_IFREG
> 0600, st_size=0, ...}) = 0
> close(8)                                = 0
> getpid()                                = 23074
> writev(2, [{iov_base="obexd[23074]: open(/home/user"..., iov_len=92},
> {iov_base="\n", iov_len=1}], 2) = 93
> sendto(3, "<27>Nov  5 18:04:33 obexd[23074]"..., 112, MSG_NOSIGNAL, NULL, 0)
> = 112
> getpid()                                = 23074
> writev(2, [{iov_base="obexd[23074]: PUT(0x2), Forbidde"..., iov_len=39},
> {iov_base="\n", iov_len=1}], 2) = 40

But then obexd claimed the open *failed*.

> so you see it resolves the link, but then fails with Forbidden.

If obexd doesn't like the path that you've given it, due to too-loose
permissions or whatever, it ought to give a clearer message to indicate
this.

In the absence of a useful error message, you could either source-dive
into obexd and try to figure out what it's actually doing... or you could
*guess* (as I am currently guessing) that it's complaining about
too-loose permissions, and then look at all the permissions of all the
subdirectories along the /home-lisa/user/Downloads path, and see if one
of them is group-writable or world-writable.  If so, fix it, and see if
that makes the problem go away.

[toc] | [prev] | [next] | [standalone]

#241900

Fromdeloptes <emanoil.kotsev@deloptes.org>
Date2021-11-05 19:20 +0100
Message-ID<DgbYK-4GW-3@gated-at.bofh.it>
In reply to#241897
Greg Wooledge wrote:

> In the absence of a useful error message, you could either source-dive
> into obexd and try to figure out what it's actually doing... or you could
> *guess* (as I am currently guessing) that it's complaining about
> too-loose permissions, and then look at all the permissions of all the
> subdirectories along the /home-lisa/user/Downloads path, and see if one
> of them is group-writable or world-writable.  If so, fix it, and see if
> that makes the problem go away.

IMO it is obviously the link, because obexd can write
to /data/local/Downloads but not to the link to this directory, which is 
/data/local/Downloads.test

I will have a look into the code over the weekend.

thanks and BR

-- 
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0

[toc] | [prev] | [next] | [standalone]

#241893

Fromdeloptes <emanoil.kotsev@deloptes.org>
Date2021-11-05 18:10 +0100
Message-ID<DgaSZ-45d-5@gated-at.bofh.it>
In reply to#241888
Greg Wooledge wrote:

> So, never mind.  Continue whatever other investigations you have lined
> up.

Ah yes, obexd is meant to be run at user level. In my case it is started by
a master application, but anyway thank you for the effort.

-- 
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0

[toc] | [prev] | [next] | [standalone]

#241895

FromGreg Wooledge <greg@wooledge.org>
Date2021-11-05 18:20 +0100
Message-ID<Dgb2G-48p-3@gated-at.bofh.it>
In reply to#241893
On Fri, Nov 05, 2021 at 06:00:43PM +0100, deloptes wrote:
> Greg Wooledge wrote:
> 
> > So, never mind.  Continue whatever other investigations you have lined
> > up.
> 
> Ah yes, obexd is meant to be run at user level. In my case it is started by
> a master application, but anyway thank you for the effort.

WHAT application?  And how is THAT creature spawned?

[toc] | [prev] | [next] | [standalone]

#241898

Fromdeloptes <emanoil.kotsev@deloptes.org>
Date2021-11-05 19:10 +0100
Message-ID<DgbP3-4DI-1@gated-at.bofh.it>
In reply to#241895
Greg Wooledge wrote:

> WHAT application?  And how is THAT creature spawned?

Sorry for confusion. For testing I run it on the command line, but it is
meant to be spawned from one BT manager application. It is spawned as
process the same way I start it in the command line.

-- 
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0

[toc] | [prev] | [next] | [standalone]

#241899

From"Thomas Schmitt" <scdbackup@gmx.net>
Date2021-11-05 19:10 +0100
Message-ID<DgbP3-4DI-5@gated-at.bofh.it>
In reply to#241898
Hi,

deloptes wrote:
> lstat("/home", {st_mode=S_IFLNK|0777, st_size=10, ...}) = 0
> readlink("/home", "home-lisa/", 4095)   = 10

Can it be that obexd is allergic to symbolic links ?

  https://discussion.fedoraproject.org/t/cannot-receive-file-over-bluetooth/1813/3
points to
  https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/obexd/plugins/filesystem.c#n95
which spews -EPERM if not obex_option_symlinks() is true.

Above discussion raises the question whether option --symlinks with
manually started obexd does help ?

It is remarkably difficult to find documentation about obexd's options.
My best catch is source code like:
  https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/obexd/src/main.c#n141

  { "symlinks", 'l', [...]
                "Allow symlinks leading outside of the root "
                "folder" },


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#241901

Fromdeloptes <emanoil.kotsev@deloptes.org>
Date2021-11-05 19:30 +0100
Message-ID<Dgc8p-4JY-3@gated-at.bofh.it>
In reply to#241899
Thomas Schmitt wrote:

> Can it be that obexd is allergic to symbolic links ?
> 
>
https://discussion.fedoraproject.org/t/cannot-receive-file-over-bluetooth/1813/3
> points to
>
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/obexd/plugins/filesystem.c#n95
> which spews -EPERM if not obex_option_symlinks() is true.
> 
> Above discussion raises the question whether option --symlinks with
> manually started obexd does help ?
> 
> It is remarkably difficult to find documentation about obexd's options.
> My best catch is source code like:
>
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/obexd/src/main.c#n141
> 
> { "symlinks", 'l', [...]
> "Allow symlinks leading outside of the root "
> "folder" },

Yes with this option it is working. I still wonder why this is necessary and
yes it is hard to find documentation.

thanks for the hint

regards

-- 
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web