Re: Disk quota for Jail. Discussion.
On Tue, May 26, 2009 at 10:32:24AM +0400, Menshikov Konstantin wrote: > Hi. > Jail now have no disk quotas. > Users which use jail, use separate zfs or md device for jail, but it > from a hopelessness. > It is necessary to discuss possible ways of realisation. > I suggest to make disk quotas for jail on the basis of the user quotas. > > Introduction. > User UID and GID are located in inode and are always accessible. > No information about jail in ufs is present. All activity jail is > limited root path. > > The work scheme. > In structure prison it is added structures containing disk quotas and usage. > At start Jail, we calculate the size root path and number of files in > it, thus receiving current use of a disk. > In functions of allocation of disk blocks and inode, we check quotas and > we increase current use. UFS cannot determine whether the new allocation goes under the jail root or not. > If jail exceeds a quota, inquiry about allocation of the disk block or > inode it is rejected. > After work end jail the information on disk use is lost. > > What do you think about it? > There are other offers? > -- > Menshikov Konstantin. > > ___ > 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" pgpfITxy4fyCP.pgp Description: PGP signature
Re: Disk quota for Jail. Discussion.
Kostik Belousov wrote: On Tue, May 26, 2009 at 10:32:24AM +0400, Menshikov Konstantin wrote: Hi. Jail now have no disk quotas. Users which use jail, use separate zfs or md device for jail, but it from a hopelessness. It is necessary to discuss possible ways of realisation. I suggest to make disk quotas for jail on the basis of the user quotas. Introduction. User UID and GID are located in inode and are always accessible. No information about jail in ufs is present. All activity jail is limited root path. The work scheme. In structure prison it is added structures containing disk quotas and usage. At start Jail, we calculate the size root path and number of files in it, thus receiving current use of a disk. In functions of allocation of disk blocks and inode, we check quotas and we increase current use. UFS cannot determine whether the new allocation goes under the jail root or not. Yes. But jail cannot allocate block and inode above root path. In allocation functions, whether for example ffs_alloc we have access to ucred process and we can check up there is a process in jail. If jail exceeds a quota, inquiry about allocation of the disk block or inode it is rejected. After work end jail the information on disk use is lost. What do you think about it? There are other offers? If jail will get access to disk devices in/dev/and will mount file system of a problem also will not arise, I think... Can be eat other problems which are not visible at first sight? ___ 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: Disk quota for Jail. Discussion.
On Tue, May 26, 2009 at 04:35:04PM +0400, Menshikov Konstantin wrote: > Kostik Belousov wrote: > >On Tue, May 26, 2009 at 10:32:24AM +0400, Menshikov Konstantin wrote: > >>In structure prison it is added structures containing disk quotas and > >>usage. > >>At start Jail, we calculate the size root path and number of files in > >>it, thus receiving current use of a disk. > >>In functions of allocation of disk blocks and inode, we check quotas and > >>we increase current use. > >> > >UFS cannot determine whether the new allocation goes under the jail > >root or not. > > > Yes. But jail cannot allocate block and inode above root path. In > allocation functions, whether for example ffs_alloc we have access to > ucred process and we can check up there is a process in jail. Yes, you can check this for jailed process. Think about non-jailed processes that can do allocation below the jail root. pgp5HrqZs2NQS.pgp Description: PGP signature
Re: Disk quota for Jail. Discussion.
Kostik Belousov wrote: On Tue, May 26, 2009 at 04:35:04PM +0400, Menshikov Konstantin wrote: Kostik Belousov wrote: On Tue, May 26, 2009 at 10:32:24AM +0400, Menshikov Konstantin wrote: In structure prison it is added structures containing disk quotas and usage. At start Jail, we calculate the size root path and number of files in it, thus receiving current use of a disk. In functions of allocation of disk blocks and inode, we check quotas and we increase current use. UFS cannot determine whether the new allocation goes under the jail root or not. Yes. But jail cannot allocate block and inode above root path. In allocation functions, whether for example ffs_alloc we have access to ucred process and we can check up there is a process in jail. Yes, you can check this for jailed process. Think about non-jailed processes that can do allocation below the jail root. Processes out of jail are not considered. I do not understand, these processes have what relation to disk to quotas for jail. Please explain more in detail ___ 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: Disk quota for Jail. Discussion.
On Tue, May 26, 2009 at 05:01:27PM +0400, Menshikov Konstantin wrote: > Kostik Belousov wrote: > >On Tue, May 26, 2009 at 04:35:04PM +0400, Menshikov Konstantin wrote: > > > >>Kostik Belousov wrote: > >> > >>>On Tue, May 26, 2009 at 10:32:24AM +0400, Menshikov Konstantin wrote: > >>> > In structure prison it is added structures containing disk quotas and > usage. > At start Jail, we calculate the size root path and number of files in > it, thus receiving current use of a disk. > In functions of allocation of disk blocks and inode, we check quotas > and we increase current use. > > > >>>UFS cannot determine whether the new allocation goes under the jail > >>>root or not. > >>> > >>> > >>Yes. But jail cannot allocate block and inode above root path. In > >>allocation functions, whether for example ffs_alloc we have access to > >>ucred process and we can check up there is a process in jail. > >> > > > >Yes, you can check this for jailed process. Think about non-jailed > >processes > >that can do allocation below the jail root. > > > Processes out of jail are not considered. > I do not understand, these processes have what relation to disk to > quotas for jail. Please explain more in detail Since the processes outside of the jail may allocate or delete blocks or inodes under the jail root, doing accounting only for actions initiated by jailed processes means that accounting does not reflect reality. pgpJQq8enOmPo.pgp Description: PGP signature
Re: Disk quota for Jail. Discussion.
On Tue, 2009-05-26 at 17:01 +0400, Menshikov Konstantin wrote: > Kostik Belousov wrote: > > On Tue, May 26, 2009 at 04:35:04PM +0400, Menshikov Konstantin wrote: > > > >> Kostik Belousov wrote: > >> > >>> On Tue, May 26, 2009 at 10:32:24AM +0400, Menshikov Konstantin wrote: > >>> > In structure prison it is added structures containing disk quotas and > usage. > At start Jail, we calculate the size root path and number of files in > it, thus receiving current use of a disk. > In functions of allocation of disk blocks and inode, we check quotas and > we increase current use. > > > >>> UFS cannot determine whether the new allocation goes under the jail > >>> root or not. > >>> > >>> > >> Yes. But jail cannot allocate block and inode above root path. In > >> allocation functions, whether for example ffs_alloc we have access to > >> ucred process and we can check up there is a process in jail. > >> > > > > Yes, you can check this for jailed process. Think about non-jailed processes > > that can do allocation below the jail root. > > > Processes out of jail are not considered. > I do not understand, these processes have what relation to disk to > quotas for jail. Please explain more in detail A process outside of the jail can still write to the file system that you consider to be jailed, depending upon permissions. If all your quota calculations are only triggered by jailed processes writing to the file system, then you can exceed quota trivially. Tom ___ 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"
Help debugging kernel together with X
Hi list, I would like to ask for some help debugging the kernel. Here is the problem: I have a computer about five years old with an on-board graphics card (SiS 661). I am trying to install an ATI Radeon 128 on the AGP port. FreeBSD (FreeBSD 7.2-STABLE #10: Tue May 26 15:08:39 CEST 2009) is able to start DRM and AGP without trouble. However, whenever I start X (X.Org X Server 1.6.1; Release Date: 2009-4-14; Build Date: 11 May 2009 12:03:27PM) the system freezes with a blank screen with some apparent noisy green dots on it (reproducible, however). It does not panic, nor reboot. Now I suspect there is some problem on the AGP bridge driver since linux can run X without trouble (i.e. hardware and BIOS are ok). I have found someone reporting problems with this bridge long time ago with no answers (http://www.nabble.com/agp-on-sis-661-td1446998.html). So here I am trying to figure out where the system freezes. I have recompiled my kernel adding the following options: options KDB options DDB options MP_WATCHDOG options SW_WATCHDOG I am able to enter the debugger with ctrl+alt+esc from a console. So what I am trying to do is to have watchdogd time out and the debugger make a dump: ddb script kern.enter.watchdog=call doadump; reboot However, when I start X no timeout occurs, and the system stays freezed. Am I missing something on the workings of watchdogd? Thanks a lot for your help! Fernando ___ 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: Disk quota for Jail. Discussion.
Menshikov Konstantin wrote: > Hi. > Jail now have no disk quotas. > Users which use jail, use separate zfs or md device for jail, but it > from a hopelessness. Well, the ZFS way of doing things (per-filesystem quotas) is actually the right way to do it - it solves exactly the problem described. signature.asc Description: OpenPGP digital signature
Re: Help debugging kernel together with X
Hi, Fernando 2009/5/26 Fernando Herrero Carrón : > Hi list, > > I would like to ask for some help debugging the kernel. > > Here is the problem: > > I have a computer about five years old with an on-board graphics card > (SiS 661). I am trying to install an ATI Radeon 128 on the AGP port. > FreeBSD (FreeBSD 7.2-STABLE #10: Tue May 26 15:08:39 CEST 2009) is able > to start DRM and AGP without trouble. However, whenever I start X (X.Org > X Server 1.6.1; Release Date: 2009-4-14; Build Date: 11 May 2009 > 12:03:27PM) the system freezes with a blank screen with some apparent > noisy green dots on it (reproducible, however). It does not panic, nor > reboot. > > Now I suspect there is some problem on the AGP bridge driver since linux > can run X without trouble (i.e. hardware and BIOS are ok). I have found > someone reporting problems with this bridge long time ago with no > answers (http://www.nabble.com/agp-on-sis-661-td1446998.html). > > So here I am trying to figure out where the system freezes. I have > recompiled my kernel adding the following options: > > options KDB > options DDB > options MP_WATCHDOG > options SW_WATCHDOG > > I am able to enter the debugger with ctrl+alt+esc from a console. So > what I am trying to do is to have watchdogd time out and the debugger > make a dump: > > ddb script kern.enter.watchdog=call doadump; reboot > > However, when I start X no timeout occurs, and the system stays freezed. > Am I missing something on the workings of watchdogd? > What you're describing does not appear to be a kernel problem; it sounds like the typical 'Xorg update from hell' problem most experienced a while back. Have a look at /usr/ports/UPDATING, and search for 'AllowEmptyInput'. Adding the following to xorg.conf should correct the problem: Section "ServerFlags" option "AllowEmptyInput" "off" option "AutoAddDevices" "off" EndSection HTH -- Glen Barber ___ 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: Disk quota for Jail. Discussion.
Tom Evans wrote: On Tue, 2009-05-26 at 17:01 +0400, Menshikov Konstantin wrote: Kostik Belousov wrote: On Tue, May 26, 2009 at 04:35:04PM +0400, Menshikov Konstantin wrote: Kostik Belousov wrote: On Tue, May 26, 2009 at 10:32:24AM +0400, Menshikov Konstantin wrote: In structure prison it is added structures containing disk quotas and usage. At start Jail, we calculate the size root path and number of files in it, thus receiving current use of a disk. In functions of allocation of disk blocks and inode, we check quotas and we increase current use. UFS cannot determine whether the new allocation goes under the jail root or not. Yes. But jail cannot allocate block and inode above root path. In allocation functions, whether for example ffs_alloc we have access to ucred process and we can check up there is a process in jail. Yes, you can check this for jailed process. Think about non-jailed processes that can do allocation below the jail root. Processes out of jail are not considered. I do not understand, these processes have what relation to disk to quotas for jail. Please explain more in detail A process outside of the jail can still write to the file system that you consider to be jailed, depending upon permissions. If all your quota calculations are only triggered by jailed processes writing to the file system, then you can exceed quota trivially. Tom The primary goal of disk quotas to limit allocation of disk blocks and inode to processes in jail during their work. Jail it is time essence. After end of work Jail, it does not exist. Let's consider disk quotas for Jail, as number of blocks or inode which jail can use during a session. I understand that if process out of jail will create in a root directory jail a file of the sizes in 1 GB, and process in jail will remove this file jail can exceed the limit on 1 GB. But there is no real necessity, in an operating time jail to write down in the root catalogue jail from the outside jail. ___ 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"
MosChip 7840 dual port ucom
Dear colleagues, any hints/directions to get MosChip 7840 dual port USB to RS232 adapter working? In usbdevs output the device is shown as port 1 addr 2: high speed, power 100 mA, config 1, product 0x7840(0x7840), vendor 0x9710(0x9710), rev 0.01 Thanks in advance. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.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"
Re: Disk quota for Jail. Discussion.
Ivan Voras wrote: Menshikov Konstantin wrote: Hi. Jail now have no disk quotas. Users which use jail, use separate zfs or md device for jail, but it from a hopelessness. Well, the ZFS way of doing things (per-filesystem quotas) is actually the right way to do it - it solves exactly the problem described. Yes, you are right. But this way, has some lacks. 1. For quota change jail, it is necessary to stop jail and to start procedure of change of the size of file system. In case of use ufs it is not simple. 2. In case of use zfs, as far as I know, it is impossible to use virtual file systems for example unionfs. ___ 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: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
[moving from security@ to hack...@]
Jakub Lach writes:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/21768
Like bde@ pointed out, the patch is incorrect. It moves the test for
v_type != VDIR up to a point where, in the case of a symlink, v_type is
always (by definition) VLNK.
The reason why the current code does not work is that, in the symlink
case, the v_type != VDIR test is never reached: we will have jumped to
either bad2 or success. However, it should be safe to move the test to
after the success label, because trailing_slash is only ever true for
the last component of the path we were asked to look up (see lines 520
through 535).
The attached patch should work.
DES
--
Dag-Erling Smørgrav - d...@des.no
Index: sys/kern/vfs_lookup.c
===
--- sys/kern/vfs_lookup.c (revision 192614)
+++ sys/kern/vfs_lookup.c (working copy)
@@ -800,14 +800,6 @@
goto success;
}
- /*
- * Check for bogus trailing slashes.
- */
- if (trailing_slash && dp->v_type != VDIR) {
- error = ENOTDIR;
- goto bad2;
- }
-
nextname:
/*
* Not a symbolic link. If more pathname,
@@ -861,6 +853,14 @@
VOP_UNLOCK(dp, 0);
success:
/*
+ * Check for bogus trailing slashes.
+ */
+ if (trailing_slash && dp->v_type != VDIR) {
+ error = ENOTDIR;
+ goto bad2;
+ }
+
+ /*
* Because of lookup_shared we may have the vnode shared locked, but
* the caller may want it to be exclusively locked.
*/
___
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: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Dag-Erling Smørgrav writes: > The attached patch should work. Oops. It actually triggers a KASSERT. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Dag-Erling Smørgrav writes: > Like bde@ pointed out, the patch is incorrect. It moves the test for > v_type != VDIR up to a point where, in the case of a symlink, v_type is > always (by definition) VLNK. Hmm, actually, symlinks are resolved in namei(), not lookup(). This is not going to be pretty. I'll be back later... DES -- Dag-Erling Smørgrav - d...@des.no ___ 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"
