Re[2]: ucred when euid/egid
Thank you for reply. So, seteuid/gid isn't enough to gain group access as for real uid. But how i can achieve this? What functions should i call from 'theprog' to gain access for the groups euid user belongs to? May be i solve the problem in wrong way? The full problem is: There is a file owned by group filegroup: rw-rw someone:filegroupthefile There is a programs data owned by group proggroup: rw-rw someone2:proggroupprogdata I need a program (theprog) that can access 'thefile' and 'progdata' simultaneously. Program can be executed by anyone. My idea was to seteuid theprog to user who is memeber of one group (filegroup) and setegid theprog to another group (proggroup). In that way i was going to give theprog rights to work with both files. P.S. I don't want to use file ACLs. Saturday, November 28, 2009, 9:28:03 PM, you wrote: Hello, I face some misunderstood situation related to the access permissions. There is a program(script) with the suid/sgid (mode 6555): r-sr-sr-x fuser:proggroup theprog There is a file: rw-rw someone:filegroupthefile User 'fuser' (==program euid) have primary group 'filegroup'(==group, who can read/write thefile). Program try to read(write) thefile and fail with permissions. I don't fully understand why. CR There is no bug; when you use the suid/sgid facility, the program CR gains the effective user ID and/or the effective GID of the executable. CR It does *not* gain any gids which the effective user is added to at CR login. CR man seteuid for more info. CR In what you have shown, theprog has neither the same user (fuser vs. CR someone) nor the same group (proggroup vs. filegroup) as the file you CR want it to modify. CR For what you want to do to work correctly, you would need to either CR make theprog's ownership be: CR anyuser:filegroup CR or CR fuser:proggroup CR -- Clifton -- Best regards, Anthonymailto:a...@mail.ru ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
[patch] Improved jail fstab functionality inside rc.d (needs testers and review)
My apologies if these are the wrong lists for this sort of thing but it was unclear to me where else to go with additions like this. I just finished hacking /etc/rc.d/jail to fix my two pet peeves, currently the rc framework only accepts a single fstab file per jail and (worse!) there is no way to specify the mountpoints in these fstab files relative to the jails root. This makes sharing of mounts (for example all my jails nullfs mounting the same ports tree) very cumbersome. This patch should allow you to specify multiple fstab files in the jail_fstab and jail_name_fstab variables and mount these in order. In addition the patch mangles the fstab files in such a way that any mountpoint in the fstab files starting with the text ROOT will have ROOT replaced with the jails rootdir. For example the following situation: rc.conf: jail_test_rootdir=/usr/jails/test jail_test_fstab=/usr/jails/fstab /usr/jails/fstab.test /usr/jails/fstab: /usr/ports ROOT/usr/ports nullfs ro 0 0 /usr/jails/fstab.test /path/to/some/folderROOT/folder nullfs rw 0 0 This should result in /path/to/some/folder being mounted into /usr/jails/test/folder and /usr/ports into /usr/jails/test/usr/ports. Normal mountpoints (i.e. not prefixed with ROOT) should still be mounted as normal. Todo: The code probably needs cleaning up, it tried to confirm to the style of the surrounding code, but I didn't know how to handle stuff which resulted in either lines longer then 80 chars or very ugly line wrapping. Someone more at home in the rc.d framework should probably clean the patch up a little to conform to the style. In addition the ROOT prefix is now hardcoded, perhaps this should be a configurable option (jail_prefix) or something instead. If people have the time to review and/or test this patch I'd be grateful any comments/critiques are welcome. Please CC me when replying to this e-mail as I'm not currently subscribed to hackers@ or r...@. Kind regards, Merijn Verstraaten jail.diff Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: heap limits: mmap(2) vs. break(2) on i386
On Fri, 27.11.2009 at 18:22:38 -0800, Maxim Sobolev wrote: Crazy idea, perhaps, but has anyone considered wrapping up sbrk(2) into mmap(2), so that there is only one memory pool to draw from? Switch to 64-bit certainly helps, however there are lot of 32-bit machines hanging around and we will see them for a while in the embedded space. Certainly current situation with two separate sources of heap memory is not normal. Alternative and very low tech test: - Remove sbrk() from libc and /usr/include - Run port test build - ??? - PROFIT! It shall be interesting to see which ports blow up thanks to sbrk() missing. Regards, Uli ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [patch] Improved jail fstab functionality inside rc.d (needs testers and review)
On Sun, 29 Nov 2009, Merijn Verstraaten wrote: My apologies if these are the wrong lists for this sort of thing but it was unclear to me where else to go with additions like this. You may try freebsd-jail@ Make sure to get a review from simon@ for this. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
definitive way to set uname in jail?
It seems that the only way to set the output of uname in a jail is to define environment variables. Unfortunately, there doesn't seem to be a reliable way to unconditionally set them (a process might do the equivalent of 'env -i /bin/sh' and unset them, etc). Apart from just patching the uname utility before I copy it into a jail, is there really a good way to do this? I would love to just be able to set a sysctl and have this work. $ jls | grep i386 29 127.1.0.13 7.2-i386-gnat_build /usr/jails/7.2-i386-gnat_build $ sudo jexec 29 csh FreeBSD 7.2-i386-gnat_build 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Regards, xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ucred when euid/egid
On Sun, Nov 29, 2009 at 01:19:02PM +0300, Anthony Pankov wrote: Thank you for reply. So, seteuid/gid isn't enough to gain group access as for real uid. But how i can achieve this? What functions should i call from 'theprog' to gain access for the groups euid user belongs to? May be i solve the problem in wrong way? The full problem is: There is a file owned by group filegroup: rw-rw someone:filegroupthefile There is a programs data owned by group proggroup: rw-rw someone2:proggroupprogdata I need a program (theprog) that can access 'thefile' and 'progdata' simultaneously. Program can be executed by anyone. This is a clearer statement of the problem, in terms of what you're trying to accomplish. If you can make the program data owned by a special program user, and require the users of the program to make their files group-accessible by this special filegroup, then you can do it fairly simply, like this: Make each users' thefile be owned by group filegroup, for example: rw-rw someone:filegroup~someone/thefile rw-rw someone2:filegroup ~someone2/thefile rw-rw someone3:filegroup ~someone3/thefile ... Make the program's data file owned by *user* proguser: rw-rw proguser:proggroupprogdata Now you can make the program setuid proguser/setgid filegroup: r-sr-sr-x proguser:filegrouptheprog This lets it be executed by any user and access its own data (via the suid) and the files the users have put into filegroup (via the sgid). Note that the users should not themselves be members of filegroup unless it's OK for them to read/write each others' data. You may need either to provide an sgid utility which can be used to create or chown that file to filegroup, or require them to be put in a shared directory with filegroup gid and the directory sticky bit set. Alteratively you could drop the sgid and simply require the file be group readable/writable by the user's own group. In that case you have r-sr-xr-x proguser:bin theprog and rw-rw someone:somegroup~someone/thefile My idea was to seteuid theprog to user who is memeber of one group (filegroup) and setegid theprog to another group (proggroup). In that way i was going to give theprog rights to work with both files. P.S. I don't want to use file ACLs. The standard Unix permissions aren't really extensible in that way. You can do it as I've outlined above; that's getting close to the limits of what you can readily do with the standard permissions. If it gets more complicated, you will need to either do ACLs or something still more creative. sudo, for instance, does allow you to set a vector of groups to match the user you're executing as. It may be possible to leverage the sudo command into doing something more elaborate if you need to, with a suitably crafted sudoers config file; you could also look into the code that sudo uses to set the group vector, but that will require you to write a suid root utility which adds a lot of security risks. Hope this helps, -- Clifton -- Clifton Royston -- clift...@iandicomputing.com / clift...@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ucred when euid/egid
On Sun, 29 Nov 2009, Clifton Royston wrote: On Sun, Nov 29, 2009 at 01:19:02PM +0300, Anthony Pankov wrote: Thank you for reply. So, seteuid/gid isn't enough to gain group access as for real uid. But how i can achieve this? What functions should i call from 'theprog' to gain access for the groups euid user belongs to? May be i solve the problem in wrong way? The full problem is: There is a file owned by group filegroup: rw-rw someone:filegroupthefile There is a programs data owned by group proggroup: rw-rw someone2:proggroupprogdata I need a program (theprog) that can access 'thefile' and 'progdata' simultaneously. Program can be executed by anyone. This is a clearer statement of the problem, in terms of what you're trying to accomplish. If you can make the program data owned by a special program user, and require the users of the program to make their files group-accessible by this special filegroup, then you can do it fairly simply, like this: Make each users' thefile be owned by group filegroup, for example: rw-rw someone:filegroup~someone/thefile rw-rw someone2:filegroup ~someone2/thefile rw-rw someone3:filegroup ~someone3/thefile ... Make the program's data file owned by *user* proguser: rw-rw proguser:proggroupprogdata Now you can make the program setuid proguser/setgid filegroup: r-sr-sr-x proguser:filegrouptheprog This lets it be executed by any user and access its own data (via the suid) and the files the users have put into filegroup (via the sgid). If you can't make progdata owned by proguser, or if more groups are needed, you might be able to abuse newgrp(1), which will let you run a program with your real and effective gids set to any specified group of which your real uid is a member. This would require, though, that you break the code that requires access to those files into separate programs. (Though maybe they are as simple as cat'ing a file into a pipe or something.) Example: setuid(proguser); FILE *data = popen(echo \cat progdata\ | newgrp proggroup, r); /* read data */ etc. If your program needs to do something really elaborate with the files that can't be factored out into a separate program, you could use newgrp to run a program that opens the file and passes its fd over a unix socket. But then it's really becoming a hack. :) Caution: I haven't tested any of this. -- Nate Eldredge n...@thatsmathematics.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
