vsftpd security issue

Hi all

This is about the vsftpd server version 2.0.3-1.

When I connect as a local user, then uploaded files are unexpectedly
owned by group "users" not the original group of the local user.

I tried both standalone and xinetd configurations - same result.

How does everybody else cope with this?

How can I fix it? I am desparate!

Are there any newsgroups that would be better suited for posting this?

Many thanks

Bernard

Bernard wrote:
> Hi all
>
> This is about the vsftpd server version 2.0.3-1.
>
> When I connect as a local user, then uploaded files are unexpectedly
> owned by group "users" not the original group of the local user.
>
> I tried both standalone and xinetd configurations - same result.
>
> How does everybody else cope with this?
>
> How can I fix it? I am desparate!
>
> Are there any newsgroups that would be better suited for posting this?
>
> Many thanks
>
> Bernard

This is a groups issue. Make sure that on the remote end, the user(s) in
question belong to the same group as the local user. You can also take a
look at the vsftpd.conf man page for more information about file
properties such as umask. The man page is also available at
http://vsftpd.beasts.org/vsftpd_conf.html

Hi Dude

You are right this is a "groups" issue which is what I am saying: I
have "user1" in "group1", and I connect as "user1".
Then uploaded files are owned by group "users" where in fact they
should be owned by group "group1".

The active parameters in vsftpd.conf are as follows:

anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=002
chroot_local_user=YES
pam_service_name=vsftpd
userlist_enable=YES
listen=YES
tcp_wrappers=YES

Any ideas?

I have this SELinux installed which might cause this but this is pure
speculation.

It would be nice if someone could produce a counter case by trying
this with user user1 in group1 and check what the owning group of an
uploaded file is.

Thanks

Bernard

Some Dude <(E-Mail Removed)> wrote:

>Bernard wrote:
>> Hi all
>>
>> This is about the vsftpd server version 2.0.3-1.
>>
>> When I connect as a local user, then uploaded files are unexpectedly
>> owned by group "users" not the original group of the local user.
>>
>> I tried both standalone and xinetd configurations - same result.
>>
>> How does everybody else cope with this?
>>
>> How can I fix it? I am desparate!
>>
>> Are there any newsgroups that would be better suited for posting this?
>>
>> Many thanks
>>
>> Bernard
>
>This is a groups issue. Make sure that on the remote end, the user(s) in
>question belong to the same group as the local user. You can also take a
>look at the vsftpd.conf man page for more information about file
>properties such as umask. The man page is also available at
>http://vsftpd.beasts.org/vsftpd_conf.html

In comp.os.linux.security Some Dude <(E-Mail Removed)> wrote:
> Bernard wrote:
>> Hi all
>>
>> This is about the vsftpd server version 2.0.3-1.
>>
>> When I connect as a local user, then uploaded files are unexpectedly
>> owned by group "users" not the original group of the local user.
>>
>> I tried both standalone and xinetd configurations - same result.
>>
>> How does everybody else cope with this?
>>
>> How can I fix it? I am desparate!
>>
>
> This is a groups issue.

It might be the "set group ID" bit set on that directory, or its parent.
If that's the case, then all files created in there will belong to the
same group as the directory itself.

--
andrei

Bernard wrote:
> Hi Dude
>
> You are right this is a "groups" issue which is what I am saying: I
> have "user1" in "group1", and I connect as "user1".
> Then uploaded files are owned by group "users" where in fact they
> should be owned by group "group1".
>
> The active parameters in vsftpd.conf are as follows:
>
> anonymous_enable=NO
> local_enable=YES
> write_enable=YES
> local_umask=002
> chroot_local_user=YES
> pam_service_name=vsftpd
> userlist_enable=YES
> listen=YES
> tcp_wrappers=YES
>
> Any ideas?
>
> I have this SELinux installed which might cause this but this is pure
> speculation.
>
> It would be nice if someone could produce a counter case by trying
> this with user user1 in group1 and check what the owning group of an
> uploaded file is.
>
> Thanks
>
> Bernard
>
> Some Dude <(E-Mail Removed)> wrote:
>
>> Bernard wrote:
>>> Hi all
>>>
>>> This is about the vsftpd server version 2.0.3-1.
>>>
>>> When I connect as a local user, then uploaded files are unexpectedly
>>> owned by group "users" not the original group of the local user.
>>>
>>> I tried both standalone and xinetd configurations - same result.
>>>
>>> How does everybody else cope with this?
>>>
>>> How can I fix it? I am desparate!
>>>
>>> Are there any newsgroups that would be better suited for posting this?
>>>
>>> Many thanks
>>>
>>> Bernard
>> This is a groups issue. Make sure that on the remote end, the user(s) in
>> question belong to the same group as the local user. You can also take a
>> look at the vsftpd.conf man page for more information about file
>> properties such as umask. The man page is also available at
>> http://vsftpd.beasts.org/vsftpd_conf.html
>

If the "user1" belongs to "group1" at both ends, then it's something
more, like you mention, SELinux. I installed VSFTPD, enabled local
users, connected to the server with "user1" that belongs to "group1" (on
the server end and the local end), and uploaded a file, which resulted
in that file being owned by "user1"/"group1". I then stopped the server,
changed "user1"/"users", restarted the server, connected as "user1",
uploaded a file, which resulted in that file belonging to "user1" but
with "users" as the group. I changed the "user1" group back to "group1",
which resulted in uploaded files belonging to "user1"/"group1". The
group changes I made were in the /etc/passwd file, which are the default
groups, which programs rely on for file creation, unless it's an option
for the program/service.

Bernard <(E-Mail Removed)> (06-07-26 21:44:47):

> When I connect as a local user, then uploaded files are unexpectedly
> owned by group "users" not the original group of the local user.

This looks like a really simple issue. Are you running the daemon as
root? If not, then all files created by it will have the same user and
group name as the daemon itself (since it's unable to change them).

This, by the way, should not mean that it's a good idea to run it as
root!


Regards,
E.S.

Please let me repeat my issue:

This is about the vsftpd server version 2.0.3-1.

When I connect as a local user, then uploaded files are unexpectedly
owned by group "users" not the original group of the local user.

I tried both standalone and xinetd configurations - same result.

How does everybody else cope with this?

How can I fix it? I am desparate!

Are there any newsgroups that would be better suited for posting this?

Some Dude <(E-Mail Removed)> wrote:
>This is a groups issue. Make sure that on the remote end, the user(s) in
>question belong to the same group as the local user. You can also take a
>look at the vsftpd.conf man page for more information about file
>properties such as umask. The man page is also available at
>http://vsftpd.beasts.org/vsftpd_conf.html

What exactly does it mean that

>on the remote end, the user(s) in question belong to the same group as the local user

I am connecting with FTP clients on various different operating
systems that require a user ID and password. I understand that you
refer to my client side as the remote end.
But that user ID does not necessary exist on the clients, so where in
the vsftp documentation do I find a requirement that on the remote
side (i.e. FTP client computer)
a) the same user has to exist
b) the same group has to exist and the user has to belong to the same
group as on the computer where the FTP server runs?

I am totally confused now.

Thanks

Bernard

Ertugrul,

Thanks for your reply.

Yes the daemon runs as root.

Regards

Ertugrul Soeylemez <(E-Mail Removed)> wrote:

>Bernard <(E-Mail Removed)> (06-07-26 21:44:47):
>
>> When I connect as a local user, then uploaded files are unexpectedly
>> owned by group "users" not the original group of the local user.
>
>This looks like a really simple issue. Are you running the daemon as
>root? If not, then all files created by it will have the same user and
>group name as the daemon itself (since it's unable to change them).
>
>This, by the way, should not mean that it's a good idea to run it as
>root!
>
>
>Regards,
>E.S.

Bernard wrote:
> Please let me repeat my issue:
>
> This is about the vsftpd server version 2.0.3-1.
>
> When I connect as a local user, then uploaded files are unexpectedly
> owned by group "users" not the original group of the local user.
>
> I tried both standalone and xinetd configurations - same result.
>
> How does everybody else cope with this?
>
> How can I fix it? I am desparate!
>
> Are there any newsgroups that would be better suited for posting this?
>
> Some Dude <(E-Mail Removed)> wrote:
>> This is a groups issue. Make sure that on the remote end, the user(s) in
>> question belong to the same group as the local user. You can also take a
>> look at the vsftpd.conf man page for more information about file
>> properties such as umask. The man page is also available at
>> http://vsftpd.beasts.org/vsftpd_conf.html
>
> What exactly does it mean that
>
>> on the remote end, the user(s) in question belong to the same group as the local user
>
> I am connecting with FTP clients on various different operating
> systems that require a user ID and password. I understand that you
> refer to my client side as the remote end.
> But that user ID does not necessary exist on the clients, so where in
> the vsftp documentation do I find a requirement that on the remote
> side (i.e. FTP client computer)
> a) the same user has to exist
> b) the same group has to exist and the user has to belong to the same
> group as on the computer where the FTP server runs?
>
> I am totally confused now.
>
> Thanks
>
> Bernard

Actually I was viewing the situation from the user side, local, and
refering to the server end as remote. Check that on the server end, the
default group for the user(s) is set to what you want the created files
to belong to. So that if user1 belongs to group1 on the server where
VSFTPD is run, the files should belong, by default, to that user and
it's group. The only other thing that might affect wrong groups for
files is a directory that belongs to another group and has the set group
ID bit (s) set for the groups permissions.