Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
sshfs and permissions
596 views
Skip to first unread message
Pierre Penninckx
Mar 7, 2012, 12:30:02 PM3/7/12
to
Hi all,
I'm using sshfs to access files on my server and it works great.
However I have a problem with permissions.
But first, my setup:
I have a server where I put all my
movies/musics/pictures/documents/backups of laptops/git projects.
It works with raid1 and lvm so it is quite secure and infinitely
scalable (well... I still need to buy hard drives).
This server will be accessible mostly by my family, some friends and
maybe some co-workers.
Every service one can access will be under /srv (/srv/movies,
/srv/pictures, etc.) or under /home/<username>.
Most of the computers are laptops. I have a Mac, my mom has a linux
OS, and my sister who lives in another house has a windows OS.
I'd like a quite basic permission system:
Family can do anything on the files but delete other's files;
Friends can only add or read;
And some friends will be able to write to git projects.
I don't explicitly need a chrooted environment.
I managed to do everything through ACLs apart making friends add
things and not delete other things:
in fact this would work if the sticky bit (chmod +t) could be
inherited when creating a new directory but it is not :/
So like I said I didn't manage to make permission 100% work through
sshfs, though it works on the server or through DokanFS.
The ACL on the /srv/movies folder is:
# file: movies
# owner: root
# group: videos
# flags: -s-
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x
(and the default user umask is 0022)
When creating a file in this directory while connect through the
server (or with DokanFS), the file has these permissions:
rw-rw-r-- fine.
But when creating it through sshfs it have:
rw-r--r-- bad.
And rwxr-xr-x for folders.
First, thanks for reading my long post.
Second, do you have any suggestions ?
I don't really know what to test.
Thanks,
Ibiz
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAMzgWy2yRoppDhW=ZjBZ29DZXO_-ZnTR9...@mail.gmail.com
I'm using sshfs to access files on my server and it works great.
However I have a problem with permissions.
But first, my setup:
I have a server where I put all my
movies/musics/pictures/documents/backups of laptops/git projects.
It works with raid1 and lvm so it is quite secure and infinitely
scalable (well... I still need to buy hard drives).
This server will be accessible mostly by my family, some friends and
maybe some co-workers.
Every service one can access will be under /srv (/srv/movies,
/srv/pictures, etc.) or under /home/<username>.
Most of the computers are laptops. I have a Mac, my mom has a linux
OS, and my sister who lives in another house has a windows OS.
I'd like a quite basic permission system:
Family can do anything on the files but delete other's files;
Friends can only add or read;
And some friends will be able to write to git projects.
I don't explicitly need a chrooted environment.
I managed to do everything through ACLs apart making friends add
things and not delete other things:
in fact this would work if the sticky bit (chmod +t) could be
inherited when creating a new directory but it is not :/
So like I said I didn't manage to make permission 100% work through
sshfs, though it works on the server or through DokanFS.
The ACL on the /srv/movies folder is:
# file: movies
# owner: root
# group: videos
# flags: -s-
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x
(and the default user umask is 0022)
When creating a file in this directory while connect through the
server (or with DokanFS), the file has these permissions:
rw-rw-r-- fine.
But when creating it through sshfs it have:
rw-r--r-- bad.
And rwxr-xr-x for folders.
First, thanks for reading my long post.
Second, do you have any suggestions ?
I don't really know what to test.
Thanks,
Ibiz
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAMzgWy2yRoppDhW=ZjBZ29DZXO_-ZnTR9...@mail.gmail.com
Camaleón
Mar 8, 2012, 1:30:02 PM3/8/12
to
On Wed, 07 Mar 2012 18:27:29 +0100, Pierre Penninckx wrote:
(...)
> So like I said I didn't manage to make permission 100% work through
> sshfs, though it works on the server or through DokanFS. The ACL on the
> /srv/movies folder is: # file: movies
> # owner: root
> # group: videos
> # flags: -s-
> user::rwx
> group::rwx
> other::r-x
> default:user::rwx
> default:group::rwx
> default:other::r-x
> (and the default user umask is 0022)
>
> When creating a file in this directory while connect through the server
> (or with DokanFS), the file has these permissions:
> rw-rw-r-- fine.
> But when creating it through sshfs it have:
> rw-r--r-- bad.
> And rwxr-xr-x for folders.
>
> First, thanks for reading my long post. Second, do you have any
> suggestions ? I don't really know what to test.
I Googled a bit and found some information about this problematic. For
instance, this blog article explains the issue quite well:
SSHFS: fix for wrong file permissions on server
http://andre.frimberger.de/index.php/linux/sshfs-fix-for-wrong-file-permissions-on-server/
I don't know if that matches for your current situation nor if it helps
you in any way but maybe can trigger a light in your head :-)
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/jjato9$ek5$1...@dough.gmane.org
(...)
> So like I said I didn't manage to make permission 100% work through
> sshfs, though it works on the server or through DokanFS. The ACL on the
> /srv/movies folder is: # file: movies
> # owner: root
> # group: videos
> # flags: -s-
> user::rwx
> group::rwx
> other::r-x
> default:user::rwx
> default:group::rwx
> default:other::r-x
> (and the default user umask is 0022)
>
> When creating a file in this directory while connect through the server
> (or with DokanFS), the file has these permissions:
> rw-rw-r-- fine.
> But when creating it through sshfs it have:
> rw-r--r-- bad.
> And rwxr-xr-x for folders.
>
> First, thanks for reading my long post. Second, do you have any
> suggestions ? I don't really know what to test.
instance, this blog article explains the issue quite well:
SSHFS: fix for wrong file permissions on server
http://andre.frimberger.de/index.php/linux/sshfs-fix-for-wrong-file-permissions-on-server/
I don't know if that matches for your current situation nor if it helps
you in any way but maybe can trigger a light in your head :-)
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Rob Owens
Mar 8, 2012, 6:40:02 PM3/8/12
to
On Wed, Mar 07, 2012 at 06:27:29PM +0100, Pierre Penninckx wrote:
> Hi all,
>
> I'm using sshfs to access files on my server and it works great.
> However I have a problem with permissions.
>
I recall having similar issues several years ago. I don't remember
> Hi all,
>
> I'm using sshfs to access files on my server and it works great.
> However I have a problem with permissions.
>
exactly how I fixed it, but possibly with '-o allow_other' on the sshfs
command. Looks like you can also do '-o umask=755' and '-o
gid=something' if you need to.
-Rob
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Tom H
Mar 8, 2012, 11:10:01 PM3/8/12
to
propagates the umask of the client to the server. This works great
when the sftp server doesn’t care about the umask while creating files
or directories. But the problem is, that the openssh sftp server
indeed cares about the server side umask", so I checked the sshfs man
page and it says "On the remote computer the SFTP subsystem of SSH is
used". You should therefore be able to set the umask for sftp via the
usual wrapper script and get the umask that you want.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Pierre Penninckx
Mar 14, 2012, 7:30:03 PM3/14/12
to
2012/3/9 Tom H <tomh...@gmail.com>:
First, thank you for your help and sorry for the response delay.
Here are the options I used:
`-o uid=501 -o gid=20 -o umask=002`
For what I understand, the main purpose of these options are to fool
the client permissions.
In fact, it seems there's no relation between the permissions on the
server and the permissions seen from the client.
>From the client, all the folders and files are owned by 501/20
(user/group) and have a 775 permission (files also have 775 and not
664).
But the permissions are still working: the server does not allow me to
do actions I don't have permission to do.
For example, if on the server I create a file with
touch a && chmod 000 a
on the server if I `ls -l` it gives me:
---------- a
but on the client
-rwxrwxr-x a
@Camaleón:
I will make remarks on the link you provided me.
Approach 1: This doesn't work, for the reasons I said above.
Approach 2 & 3: These approaches are technically the same: fixing
the problem afterwards. This works great but I don't find it very neat
so I will use it if really necessary. Also, `inotifywatch` should do
the trick.
@Rob Owens:
I tried the `-o allow_other` but this only let me access the mounted
directory with another user on the client side. This doesn't fix the
problem.
@ Tom H:
This seems to be the problem but I must say that I don't really
understand what this paragraph means, especially this:
of SSH is used. You should therefore be able to set the umask for sftp
I must apologize if I didn't make it clear before, but the problem is
not only a umask problem, it's also an ACL problem (I think).
In fact, the umask of the user on the server is 002 and when I create
a file through sshfs, the permissions are correct (755 or 644).
The thing is I added default ACLs like the `default:group` option and
it doesn't seem to be applied, though if I `getfacl` on the files
created on the client side it seems the permissions are correct.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAMzgWy0Tva-ukfqYgkR+MnAJ...@mail.gmail.com
Here are the options I used:
`-o uid=501 -o gid=20 -o umask=002`
For what I understand, the main purpose of these options are to fool
the client permissions.
In fact, it seems there's no relation between the permissions on the
server and the permissions seen from the client.
>From the client, all the folders and files are owned by 501/20
(user/group) and have a 775 permission (files also have 775 and not
664).
But the permissions are still working: the server does not allow me to
do actions I don't have permission to do.
For example, if on the server I create a file with
touch a && chmod 000 a
on the server if I `ls -l` it gives me:
---------- a
but on the client
-rwxrwxr-x a
@Camaleón:
I will make remarks on the link you provided me.
Approach 1: This doesn't work, for the reasons I said above.
Approach 2 & 3: These approaches are technically the same: fixing
the problem afterwards. This works great but I don't find it very neat
so I will use it if really necessary. Also, `inotifywatch` should do
the trick.
@Rob Owens:
I tried the `-o allow_other` but this only let me access the mounted
directory with another user on the client side. This doesn't fix the
problem.
@ Tom H:
This seems to be the problem but I must say that I don't really
understand what this paragraph means, especially this:
"But the problem is, that the openssh sftp server indeed cares about
the server side umask [...] On the remote computer the SFTP subsystem
of SSH is used. You should therefore be able to set the umask for sftp
via the usual wrapper script and get the umask that you want."
What wrapper script ?
I must apologize if I didn't make it clear before, but the problem is
not only a umask problem, it's also an ACL problem (I think).
In fact, the umask of the user on the server is 002 and when I create
a file through sshfs, the permissions are correct (755 or 644).
The thing is I added default ACLs like the `default:group` option and
it doesn't seem to be applied, though if I `getfacl` on the files
created on the client side it seems the permissions are correct.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Tom H
Mar 15, 2012, 8:10:01 AM3/15/12
to
On Wed, Mar 14, 2012 at 7:21 PM, Pierre Penninckx
<Pierre.P...@gmail.com> wrote:
>
> @ Tom H:
> This seems to be the problem but I must say that I don't really
> understand what this paragraph means, especially this:
> "But the problem is, that the openssh sftp server indeed cares about
> the server side umask [...] On the remote computer the SFTP subsystem
> of SSH is used. You should therefore be able to set the umask for sftp
> via the usual wrapper script and get the umask that you want."
> What wrapper script ?
The wrapper script is to change the "Subsystem sftp ..." lin in
<Pierre.P...@gmail.com> wrote:
>
> @ Tom H:
> This seems to be the problem but I must say that I don't really
> understand what this paragraph means, especially this:
> "But the problem is, that the openssh sftp server indeed cares about
> the server side umask [...] On the remote computer the SFTP subsystem
> of SSH is used. You should therefore be able to set the umask for sftp
> via the usual wrapper script and get the umask that you want."
> What wrapper script ?
"/etc/ssh/sshd_config" to "Subsystem sftp
/usr/local/bin/sftp-server.sh" and override the default "0022" umask
by creating "/usr/local/bin/sftp-server.sh" as:
#!/bin/sh
umask 0002
/usr/lib/openssh/sftp-server
I've never seen any acl-related configuration possibilities in
sshd_config (which doesn't mean that they don't exist!). Maybe you can
set up "AllowGroups ..." and/or "Match Group ..." stanzas that'll make
ssh/sftp behave the way that you'd like them to.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages