similar to: "set owner" option for rsync client

Using OpenSSH SFTP with chroot ============================== Several people have been asking now for some kind of documentation on how to use the chroot-patch for the sftp-server. So here it comes. I hope nobody minds that i post this in the developer list. The patch has been provided to the list some time ago. I'm sorry not giving credit to the author, but I really don't know who

http://bugzilla.mindrot.org/show_bug.cgi?id=136 Summary: setgid() deemed to fail for non-suid ssh client on linux if using other than primary group Product: Portable OpenSSH Version: 3.0.2p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ______________________________________________________________________________ Caldera Systems, Inc. Security Advisory Subject: kdelibs vulnerability for setuid KDE applications Advisory number: CSSA-2000-015.0 Issue date: 2000 June, 02 Cross reference: ______________________________________________________________________________ 1.

Hello, I know this chroot issue has been brought up many times before on this list. I saw that the contribibuted chroot-patch was removed from the contrib directory because it always was out of date. The main reason was of course was that sftp-server has to be run as root to be able to do the chroot() call? Most of you are against chroot (since it isnt in the src) but I believe a lot of users

The attached patch adds an option --drop-suid which caused rsync to drop setuid/setgid permissions from the destination files. ie, even if the source file is setuid, the target file will not be. Added as we want to rsync the same files to machines both inside and outside our firewalls. For machines inside the firewall some files should be suid, for machines outside the firewalls they should

On 12.11.23 03:52, Damien Miller wrote: > On Sat, 11 Nov 2023, Bob Proulx wrote: > >> I am supporting a site that allows members to upload release files. I >> have inherited this site which was previously existing. The goal is >> to allow members to file transfer to and from their project area for >> release distribution but not to allow general shell access and not

On Sat, 11 Nov 2023, Bob Proulx wrote: > I am supporting a site that allows members to upload release files. I > have inherited this site which was previously existing. The goal is > to allow members to file transfer to and from their project area for > release distribution but not to allow general shell access and not to > allow access to other parts of the system. > >

Hi, many people are having problems using SFTP with ChrootDirectory when the jail directory (or the path above) is not owned by root. The question is if chroot'ing to usual home directories can be allowed, even though they are owned by regular users. I know that this topic has been discussed on the list several times now, so I searched the list archives for posts that invalidate the

In message <199709161652.MAA31468@ding.mailhub.com>, "Alexander O. Yuriev" writ es: > > [Mod: This message is a reason *why* linux-security is moderated list. This > is also a reason why Rogier, myself, Alan Cox and others really do not want > to have completely open lists that deal with security related aspects of > running a system as way too many people just jump

Dear all, I'm running Samba version 3.0.4 (this is what comes with Solaris 10) on a Solaris machine. For WORM file system support, a new "Snaplock"-mechanism has been implemented into SAM-FS. This mechanism uses the setting of the "setuid" bit (e. g.: "chmod 4000 <filename>") to trigger a file to become a WORM file (i. e. it cannot be modified / deleted

https://bugzilla.samba.org/show_bug.cgi?id=9246 Summary: Add chroot enablement option to rsync client Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: bmn at mailinator.com

hello friends, You are right, changed the user to root, and icmpping and icmppingsec are working now!!! Thank you!!!! On 10/26/05, Fortin, Benoit <benoit.fortin@cgi.com> wrote: > > > Hi, > > The setuid of fping was already set, as you can see : > > zabbix@wirelessKTM:~/fping-2.4b2_to$ ls -l fping > -rwsr-xr-x 1 zabbix zabbix 69258 2005-10-26 17:59 fping >

Hi Damien, Thank you. I read the rationale. Just to summarize, a user writeable chroot target is considered dangerous if: 1) the user has another way of gaining non-chrooted access to the system 2) is able to create hardlinks to setuid-binaries outside of the chroot tree 3) there are bugs somewhere that allow privilige escalation or remote execution of other programs While all these

I'm stuck on a problem with rsync... We've got a chrooted shell with rsync and all the needed libs inside (and not much else). We're using rsync over ssh to send the files into this chrooted session. The rsync binary in the chrooted session is SUID root so that it can create the files with the correct UID/GID. When the following is run, it creates all the files as root.staff, not

I think this is more a philosophical issue. Some people want all applications to be like windows. "Are you sure you want to delete this file" <YES> "really"<yes>"it might make something stop working<yes>"permission denied". Unix assumes you know what you're doing. If you don't, tough. There's no reason you can't make a

tshumway@ics.uci.edu wrote: > On Linux, running 'rsync --daemon' as root bypasses some security > restrictions, allowing access to otherwise inaccessible files. Well, I can see why you think this is confusing, but I think rsync's behaviour is reasonable and consistent with Unix's security design. > as 'nobody' I should not have been able to access *any* of the

On Fri, Jan 05, 2018 at 09:42:18PM +1030, David Newall wrote: > On 05/01/18 20:06, Jakub Jelen wrote: > > if the confined user has write access to the chroot directory, > > there are ways how to get out, gain privileges and or do other > > nasty things. > > I'm not inexperienced with UNIX and unix-like operating systems (30+ years), > and I can't think what

Hi, I need to make a custom code change in sftp-server module to copy the received file outside the chroot-setup. I am trying to chroot repeatedly to get physical root directory and the copy received file to a directory outside chrooted directory. The children processes are owned by the sftp-user and so, sftp child process does not have permission to escape out of chroot. Is there a simple way

Hello, I'm trying to export a /home/ partition for multiple users, using Samba and the setuids option. My goal is to deliver emails into $HOME/.Maildir/ for each user. So I mount the share as user "root", hoping that each user will be able to use their own home directory (just like an NFS /home/ mount). (This feature depends on the Unix extensions.) I have the

I have a use for sftp to run in a chroot jail. Since sftp doesn't quite work properly for that, I did the work to make it function like that. This required two different changes: sftpsh is a replacement for nologin. It works like nologin except under certain circumstances -- where it will start up sftp-server. The other part was to add an option to sftp-server. the '-c' option